Ahh. I think I see the problem! For some reason Bill sees this as somehow Jim's (my) fork. It's not. It's a svn branch from HEAD of trunk, which contains all the changes. That branch is the projects's branch not some personal fork, whatever that means.
> On Sep 12, 2018, at 6:49 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Wed, Sep 12, 2018, 04:16 Daniel Gruno <humbed...@apache.org > <mailto: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> > > <mailto: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> > >> <mailto:minf...@sharp.fm <mailto:minf...@sharp.fm>>> wrote: > >> > >> On 11 Sep 2018, at 20:35, Jim Jagielski <j...@jagunet.com > >> <mailto: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,
