On 09/12/2018 10:58 AM, Graham Leggett wrote:
> On 12 Sep 2018, at 03:15, William A Rowe Jr <wrowe@xxxxxxxxxxxxx
> <mailto:wrowe@xxxxxxxxxxxxx>> wrote:
>> On Tue, Sep 11, 2018, 17:42 Graham Leggett <minfrin@xxxxxxxx
>> <mailto:minfrin@xxxxxxxx>> wrote:
>> On 11 Sep 2018, at 20:35, Jim Jagielski <jim@xxxxxxxxxxx
>> <mailto:jim@xxxxxxxxxxx>> 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,