Hi, I'm a Debian Developer participating in Debian GNOME packaging and interested in the packaging of maemo apps.
On Fri, Jul 20, 2007, [EMAIL PROTECTED] wrote: > [...] But a non-stable repository is > something different: a tool for developers. > [...] There must be clear reasons to do that and a > crystal clear collection of needs and requirements. The first reason Nokia / Maemo might want to offer an unstable repository is quite certainly to ease developer participation. But I think there are two things which you're developing at the same time: - upstream development of some software (especially Hildon, misc N800 apps such as the embedded browser, some proprietary modules...) - the Maemo distribution(s) (its packaging, integration, themes and branding...) These are quite different and while you're doing both at the same time, one might wonder which one of these you're looking to open the development of. An unstable repository will always help open the participation in the distribution, and it might open the participation in the upstream development of the open source software you're upstream of. On the other hand, if your goal is to improve the development of the Hildon stack, then perhaps the important focus should be on moving to GNOME's hosting infrastructure. You mention a "non-stable" (and not "unstable") repository: perhaps you already tickled the idea of having a "testing"-style distribution? I think this is a really great concept which makes sense in the perpetually moving software landscape: you're always receiving the latest software close to its upstream release but still after a short period where important issues can be raised -- and prevent buggy software from reaching the "testing" archive. If you do want to experiment with the "perpetually up-to-date and almost-stable repository" concept, then I do think you'll need an *unstable* repository first. [...] > The maemo stack has a non-trivial size and variety of components (i.e > think of the licenses and distribution rights). Releasing a stable > version implies a lot of effort already. Don't think in coding only, > there is a lot more. For instance, legal checks of the code that is > being shipped. Moving the software integration to the public implies a > deep reorganization of parts of our process and implies also more work, > no matter how you look at it. Hmm I fail to see a huge difference here: instead of doing these checks at release time, you would probably do them at the time where you include software in the public repository. This is likely to spread the load over time, and I think the other distributions (at least Debian and Ubuntu) demonstrated the concept of a "NEW" queue [1] pretty well until now. [...] > Yes, real testing has a value but we could keep handling this by > releasing binaries and the relevant source code by pieces, as we have > done this week with the Mozilla based browser and the RTCom update. No > need to mount an entire public distro for that. Having a developer crowd get all updates all the times is very different from having to promote each individual software for each new major release. You can get pretty good bug reports -- perhaps with patches -- as the result of the combination of all new software, and some bugs might only be visible with some combinations of software or in some use cases which you might not be directly testing in your current process. While you discuss the benefits or costs of having an unstable archive with unstable software, you seem to be aware of some of the setup costs: setting up such an archive, maintaining it etc. But there's a non-technical angle that will need to be addressed as well: who do you grant access to such an archive? Will the archive only be available for Nokia folks to upload to, or will anybody be able to join a new uploaders community? How will you select people who are allowed to upload software which will be built on your build daemons and which will run on the devices of the end-users/end-developers tracking the unstable repo? IOW, are you interested in creating a new technical distribution tool fully handled by the same people currently handling Maemo, or are you interested in building a new community with its processes, rules and policies? Bye, [1] http://ftp-master.debian.org/new.html -- Loïc Minier _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
