On Tue, Mar 27, 2007 at 01:45:57PM -0700, Allison Randal wrote: > <Steve_p> It works OK if everyone agrees that one ( or a very > few) access the maintanence branch > <bernhard> How many branches are we talking about 1,2 or 10 ? > <chromatic> Steve_p, I think Nicholas might disagree that it > works okay.
Yes and no. I don't think that the stable/development spit in Perl 5 land is broken. There is a problem that there aren't enough people with good enough knowledge to be committers, and in particular to want to review and apply patches supplied by non-committers, which are often for areas that no-one is totally comfortable with. [Also, there are patches that turn out to be "works for me" whereas really for something as widespread and production critical as Perl 5 you want "I understand this code, and this is the right way to solve it" patches] Slightly detached from this is that very few people want to diagnose or fix bugs. (Which is a job, rather than fun, unless your sense of fun is somewhat puritanical*). You don't need commit access for this. > <particle> allison: as long as the development branches are > kept up-to-date wrt the stable branch, they won't diverge > <pmichaud> well, if we treat the trunk branch as being the > stable one, then there's a built-in incentive to get things checked > into > the trunk because without that new features don't make it into the release > <chromatic> particle, that's never been my experience. > <pmichaud> s/checked in/merged in/ > <allison> particle: it depends on someone actively watching > and merging changes, which is pretty much a full-time job for a > volunteer > <allison> (and not a particularly fun job) > <particle> it's a job we all do already, in a way My estimate is that for Perl 5, keeping the maintenance branch maintained is about 1 day per week. I think Rafael said that it takes about 1 day per week to keep on top of incoming patches for Perl 5. So it is a lot for a volunteer. > <chromatic> It takes the same kind of developer discipline to > manage a long-lived branch as it does to keep the trunk stable, and > managing branches adds administrative overhead and latency. In Perl 5, there is no 5.10 branch. It's the trunk. The principle reason to have a maintenance branch is that 5.8.$n+1 is binary compatible with 5.8.$n, which means that not all changes on the trunk are suitable for 5.8.x. Applying the Perl 5 philosophy to Parrot, there wouldn't be any need for a branch until 1.0 is released. > <chromatic> When smokes fail, Paul Cochrane fixes a bunch of > whitespace issues. Why do smokes fail? Are people committing things without running make test? If I arrange to kidnap Paul Cochrane, will it force a proper solution? :-) > <allison> I'm totally on board for improving our smoke system Most Perl 5 smoke systems report the bad tidings of black smoke to perl5-porters. I've never noticed a failing Parrot smoke report to this list, so I infer that they aren't set up this way. Would changing that help focus minds? > <particle> and i'm not interested in testing every revision, > when so many might be coding standards Why are people even checking things in that fail coding standards? Nicholas Clark * there's a better word than this, but it slips my mind. It's not Presbyterian, but it's a word I'd associate with it.
