develooper Front page | perl.perl5.porters | Postings from July 2010

Re: backporting into 5.12.2 -- was kill $1 broken

Thread Previous | Thread Next
Nicholas Clark
July 2, 2010 06:33
Re: backporting into 5.12.2 -- was kill $1 broken
Message ID:
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:

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 Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About