git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.4.x and 2.6.x ... next steps


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 <wrowe@xxxxxxxxxxxxx> wrote:

On Wed, Sep 12, 2018, 04:16 Daniel Gruno <humbedooh@xxxxxxxxxx> wrote:
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,