On 21/09/10 19:48, Guillaume Paumier wrote:
I can see a number of reasons to have a stable trunk (also used by Wikimedia websites), that contains reviewed& tested code, along with a development branch that/can/ be broken:
Hello,
I haven't posted in a long time but I though I could share some old knowledge and my experience on the matter.
In september 2004 (according to CVS logs), Brion or Tim made a new branch named 1.3A meant for the WMF website. The process was roughly : users commit to an unstable branch and sysadmin would choose wich commits could make it to the live site. I remember I personally crashed the site a few time by sending an incorrect patch in production (we even talked about a blank page day for me :( ). The 1.3A made it less likely since someone else reviewed trunk patches before making it to 1.3A.
With 1.6, brion started the continuous integration cycle. As I understand it, it was more about releasing stable snapshots when more and more users were begging for a new version. By this time the 1.3A idea has been abandonned and trunk was meant to be production ready. That made it hard to commit unstable patches in trunk. Instead developers made new branches that were later merged in trunk once "proven" stable. Brion, Tim, Jeluf or any old school developers would probably be more talkative about it.
In my experience, the main issue in releasing a new version is establishing a schedule and make sure the release is as bugproof as possible. The schedule could be something like : - at T0 : new features frozen (no more new code) - at T1 : i18n frozen (no new message only bug fixes / typos) create an alpha snapshot for people to test new features - at T2 : freeze non urgent commits. create a beta snapshot - at T3 : by this time most bugs have probably been tracked down. It is time for a release candidate. - at T4 : release !
That kind of schedule would help volunteer, senior developers, testers, users, translators to *focus* on a given task. Between T1 and T2 translators will be busy. In between T2 and T3 you will focus on tracking and fixing important bugs ... Of course new features can still live in their own branch.
Maybe whoever is the release manager nowaday (Tim?), could have a look or contact other release manager. KDE, Gnome, Symphony come to mind.
cheers,