Previously we use rolling release model. The advantage of this model is: 1. Most of the components are actually indepedent. Rolling release can make sure all of the users get the latest components. 2. As they are independent, there is no point in synchronize their release. 3. In this way the release of some components will be blocked by others if there are some major blockers. The only disadvantage are less advertising effect and maintainance. A major release can be done by distro makers such as Lubuntu, but major release doesn't seem to be needed for our components, especially when part of the components are borrowed from other projects, such as openbox and leafpad. But I agree that having major releases is better for promotion.
On Wed, Apr 7, 2010 at 3:27 AM, Julien Lavergne <[email protected]> wrote: > Le mardi 06 avril 2010 à 16:26 +0200, Martin Bagge / brother a écrit : >> >> We have gained alot of speed the last six month or so and I think the >> future looks bright but the lack of a proper process of things is >> disturbing and might jeopardize things. >> >> We have discussed this before and a good proposal was made with people >> agreeing to stick to it. We haven't really used it but I think we should >> give it another try. A proper release team and release process will ensure >> quality in our products and avoid shitty releases that influx on other of >> our products that has and will be great. >> >> A release team with a clear and _easy_ process. >> Using freeze periods. >> Release dependent components together - without long waiting. > >> >> Christoph and I have already told before that we are willing to work with >> this process. >> Some of the other packagers I seem to recall in this is Andrea and Andrew, >> and at IRC there have been more voices raised for this. >> As far as I can see we can cover the major distributions package managers >> as front line testers and I can handle the translation errors and call for >> updates. As long as developers just producs code and tell us when to start >> the process it will float and if you don't want to engage in the release >> process you don't have to. >> >> When do we start? Can we have a wiki page with all the relevant steps and >> procedures? >> > > Last time we talked about this topic, we said that we need to freeze > sometimes before the release for each component. > > However, with the growing of components, why not using the same process > that other DE or big project with many components : > - Set a period of development, with freezes (features, UI, string). > - Keep it for all components. > - Release all the components on one date. > > This will ensure the coherence between components, easier the read the > Roadmap/Schedule, and it's easier to advertise on it (only 1 date, > easier to prepare and to spread the work :)). > > What do you think ? > > Regards, > Julien Lavergne > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxde-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxde-list > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
