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,
--
Ashar "hashar" Voultoiz
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
