Application template

Minh Ha Duong haduong at
Tue Sep 30 08:20:23 CEST 2008

> Well, to be honest, I really hope that most programs will not need
> "Download" URL at all. I am a happy Linux user and I almost never
> install anything which is not directly available in the package sources.

This is because there are dozens of maintainers that do the quality assurance 
and integration work. Linux desktops are different from us in two critical 
- number of users is at least an order of magnitude larger
- appropriate POSIX framework has been in place for years

> Openmoko should encourage all people who makes IPK to publish it on
> Community Repository.

They already do. But I think they the bar is too high, so community-repository 
see almost no action. It's time to reconsider whatever procedures are in 
place to filter the participation in this repository. Surely, someone 
somewhere must have been playing with a more decentralized "web 2.0", way of 
distributing applications. Is there something cloudy and peer-to-peer ?

> If the maintainer does not, I hope Openmoko Inc can do the work needed
> for keeping programs available.

Sorry, I do not share your hope. My understanding of their policy is to focus 
on low level critical components: kernel + framework. Distribution is 
typically something that can be done by the community. My hopes are with the 
FDOM here. If they continue to snowball and grow, they will be the first 
specific "distribution" of Openmoko (NB: Qtopia, Debian and Gentoo are 
distributions too, but not specific. FSO, ASU and 2007.2 are more releases 
than full-fledged distributions). As such, they will be in good position to 
take the lead on creating a package maintainers team. Alternatively, I had 
the impression that in the TeX world the local user groups were very active. 
We will see where it comes from anyway...

> Am I asking for too much? :-)

  It is easy to underestimate what it takes to do good and efficient 
packaging. Knowledge of both upstream and downstream, technical and social 
skills, plus writing skills for the occasional documentation. The task has no 
end, and as a middleman, you don't get lots of visibility. I guess that most 
maintainers work on the packages they use themselves.



More information about the documentation mailing list