On Wed, 10 Jul 2013 12:43:58 -0400 Jim Jagielski <[email protected]> wrote:
> > On Jul 10, 2013, at 2:19 AM, William A. Rowe Jr. > <[email protected]> wrote: > > > So my proposal to be presented shortly as a vote would be to > > abandon the trunk into a sandbox to be mined for good changes, once > > 30 days after a vote is concluded without a release, and to revert > > the 2.4.x trunk to CTR. Comments and suggestions are welcome > > before I frame this as an actual policy vote... > > From what I can see, the above was sent at > > Received: from [173.201.193.104] (HELO > p3plsmtpa08-03.prod.phx3.secureserver.net) (173.201.193.104) by > apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:19:53 +0000 > > and the [VOTE] The 'RM' Baton was sent at: > > Received: from [68.178.252.110] (HELO > p3plsmtpa11-09.prod.phx3.secureserver.net) (68.178.252.110) by > apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jul 2013 06:41:51 +0000 > > My math may be off, but that seems like a "wait" of ~22 minutes for > the "welcome" comments and suggestions. :) What does the question of how long can a prospective RM hold that baton before it becomes an excessive period of time (being the act of one committer, whether that is you or I or another, which prevents others from offering to do so in a more timely manner)... have to do with the question of what obstacles are in the way of commit activity today, particularly a /trunk/ which has no release plans, and a cumbersome RTC process (being policy impacting each committer who attempts to improve the 2.4.x active release branch)? They are two separate matters to consider, and the second has a number of possible solutions and improvements. The former is a straightforward question, are you or I impeding others from stepping up to RM in some timely manner to offer more releases to users, based on announcing to tag and roll when no tag and roll is forthcoming? I've offered nothing to vote on with respect to the second question, because we need more input from committers about what really impedes their ability to efficiently commit to the code base. Does that clarify the distinction for you?
