On Tue, 6 Apr 2010, Mario Behling wrote: > I put up a wiki page here: http://wiki.lxde.org/en/Category:Releases > > Please correct it and adapt it so it suits the process.
Great. I'll read and change or add what I like. I encourage anyone doing the same. If you disagree with something rather make a note and state why. In some days we can bring those to the ML and choose path. > Questions to consider: > * Do we want to keep release notes in the wiki as well? I am not sure if that is valuable or just adding work load. They will be in the blog and hopefully in the source archive. > * Would it be a good idea to decide on a release manager for single > (major) components, who is the main responsible and follows up in case > the process slows down or so? Previously there did not seem to be a > need though. Yes I think so. And a fallback. A list in the Release pages with Component name, primary release driver, fallback driver and primary developers and stuff like that. Most components has few developers in the major spot IMHO. And I think a release driver can handle alot of components and the release team as a whole is the last resort if the two designated for the component is unresponsive per mail or irc. I envision the process going something like this. Developers do their work. When nearing a point in time to release they settle on the minimum requirements to go in release (the text sounds more formal than I think is necessary in real life). The release team prepare to take the release process, if the designated driver think they are unavailable they tell so and the fallback (or somebody else) will take over. When done the testing starts. Freeze for features and strings At least the major distributions should have tested and acknowledged the changes as working. The release team will request the translators to do the updates to the strings and set a last date for translation updates to be added. Build tests and release. Publish tar and release notes. Packagers push their respective distros. (I am not a developer here, nor a packager, so please help to adapt this to real life. The important things for me is a) major distros must have a working version. b) the released code must build without errors (counting every aspect of that) - if those are met at least I am happy.) For the release team the most important thing probalby is to communicate, the second most important thing is to trust each other. Somewhere about third the technical aspects rises. Having rpm guys building debs and vice versa is not anything I think we will gain from but working together where possible is. -- brother ------------------------------------------------------------------------------ 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
