Front page | perl.perl5.porters |
Postings from July 2010
On Tue, Jun 29, 2010 at 01:21:06PM -0500, Todd Rinaldo wrote: > I was thinking that we were doing this pseudo-postgres style in that the person who commits to trunk is supposed to consider whether the patch is worthy of back port into previous versions and then do the back port. This would take a major load off the release manager's back and would allow everyone to know what's coming for 5.12.2 as we go. Then all the release manager has to do is review the back ports and decide if anything crazy made it into the branch and re-base them out. Pseudo, maybe. But you're not accurately describing the plan as implemented. Jesse's plan is not that any 1 committer can (and does) backport any valid change. To do that would require that everyone committing is experienced and confident enough to make a maintenance release single handed. Of the active committers, only 4 people have done this before, and at least 2 are definitely no longer interested. If we made it a requirement that you can't commit unless you also deal with all the maintenance branches, then either a: no-one would commit b: everyone would err on the side of caution, and decide that the change was unsafe for maint. either way, near to zero changes would get to maint. Which is stable, but a little bit too stable. So, Jesse's plan, as documented: http://search.cpan.org/~mstrout/perl-5.13.2/pod/perlpolicy.pod#Getting_changes_into_a_maint_branch is that 1 committer proposes that a change be included, and any 2 others agree. This ensures code review, but also reduces the skill prerequisite and fear tolerance needed to actually get stuff done. Remember, right now, this entire edifice runs on about 6 to 8 people doing things month in, month out, and about another 8 people who are sharing the monthly releases. Plans to share the work out further tend to fail because a: other people who actually do work don't exist (even if they say they do) b: or they don't want to use their initiative to figure out what to do - telling someone else what to do takes longer and isn't as fun as doing it yourself, which is the *key* criteria when you're a volunteer with limited time c: or they start something, with the best of intentions, but never want to admit failure and return the task incomplete, so instead disappear Where are all those people now, who said that they didn't contribute to the perl core because it was in Perforce? Nicholas ClarkThread Previous | Thread Next