On Wed, Sep 12, 2018, 04:16 Daniel Gruno <humbed...@apache.org> wrote:
> On 09/12/2018 10:58 AM, Graham Leggett wrote: > > On 12 Sep 2018, at 03:15, William A Rowe Jr <wr...@rowe-clan.net > > <mailto:wr...@rowe-clan.net>> wrote: > > > >> On Tue, Sep 11, 2018, 17:42 Graham Leggett <minf...@sharp.fm > >> <mailto:minf...@sharp.fm>> wrote: > >> > >> On 11 Sep 2018, at 20:35, Jim Jagielski <j...@jagunet.com > >> <mailto:j...@jagunet.com>> wrote: > >> > >> > This is what I propose: > >> > > >> > o Later on this week I svn cp trunk over to branches/2.5.x > >> > >> > >> -1 ... Veto on the basis of project bylaws. Propose a revision for > voting. > > > > I've totally lost you. Jim describes creating a branch, how is this > > related to voting? > > I am not Bill, but it is likely a reference to the fact that you can > veto code changes, not community/workflow changes. I see Jim's proposal > as the latter, so I'm not sure why the attempted veto. The codebase > itself isn't being changed from what I can gather, only the workflow is. > Yes. To be clear, the proposal to make 2.5 Jim's fork, discarding all previously committed changes to 2.5 (and I suppose, renumbering trunk as 2.7) is a change to the project development process at httpd. As-it-stands, such a personal fork is vetoable. And flies in sharp contrast to community over code, discarding the existing collaboration of 2.5.1-dev trunk in favor of one participants agenda. Note, sandboxes are encouraged, don't require any vote to start one, and might lead to some compromise between points a and b. I suggest above, propose a *process* revision to our /dev/ docs for a vote, before proceeding to violate community norms on versioning. Sorry for the confusion about what I was proposing to 'revise'. As a project committee vote to change our operational process, that is a simple majority vote, as Daniel observes, which would carve out space for a zombie (never to be released) trunk,
