commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VOTE] Move Apache Commons to Git for SCM...
Date Wed, 16 Oct 2013 22:25:11 GMT
On 10/16/13 2:39 PM, Gary Gregory wrote:
> On Wed, Oct 16, 2013 at 5:14 PM, Mark Thomas <markt@apache.org> wrote:
>
>> On 16/10/2013 21:34, Christian Grobmeier wrote:
>>> On 14 Oct 2013, at 9:13, Mark Thomas wrote:
>>>
>>>> On 13/10/2013 23:59, sebb wrote:
>>>>> On 13 October 2013 20:47, Phil Steitz <phil.steitz@gmail.com> wrote:
>>>>>> On 10/13/13 8:09 AM, James Carman wrote:
>>>>>>> Well, it has been 72 hours, so let's tally up the votes.  As
I see it
>>>>>>> (counting votes on both lists):
>>>>>>>
>>>>>>> +1s
>>>>>>> James Carman
>>>>>>> Romain Manni-Bucau
>>>>>>> Matt Benson
>>>>>>> Benedikt Ritter
>>>>>>> Bruno Kinoshita
>>>>>>> Gary Gregory
>>>>>>> Luc Maisonobe
>>>>>>> Oliver Heger
>>>>>>> Christian Grobmeier
>>>>>>> Torsten Curdt
>>>>>>>
>>>>>>> -1s
>>>>>>> Mark Thomas
>>>>>>> Thomas Vandahl
>>>>>>> Damjan Jovanovic
>>>>>>> Gilles Sadowski
>>>>>>> Jorg Schaible
>>>>>>>
>>>>>>> +0.5
>>>>>>> Olivier Lamy
>>>>>>>
>>>>>>> +0
>>>>>>> Ralph Goers
>>>>>>>
>>>>>>> -0
>>>>>>> Emmanuel Bourg
>>>>>>>
>>>>>>> The vote passes, so Apache Commons will be moving to Git for
SCM.  We
>>>>>>> should begin working on a plan.  I propose we set up a wiki page
for
>>>>>>> that.
>>>>>> I protest.  It is fine for some components to experiment, but if
we
>>>>>> are going to force all to move, we really need consensus and that
is
>>>>>> clearly not the case here.  I did not vote as I frankly saw the VOTE
>>>>>> as premature.  We should use VOTEs as a last resort, not a first
>>>>>> step or way to avoid getting to consensus on non-release issues.
>>>>> I agree entirely with Phil.
>>>>>
>>>>> I would have voted -1 earlier, but was off-line for a few days.
>>>>> This is a huge change, and should not be bulldozed through.
>>>> I too challenge the assertion that there is consensus for this change.
>>>>
>>>> I also agree with Sebb's characterisation of this being "bulldozed
>>>> through".
>>> I disagree.
>>>
>>> We have discussed it, we had a vote. We have not voted to push a red
>>> button on friday
>>> and to work with git alone on saturday. This was a vote for a general
>>> decision and
>>> it is clear (or should be) that changes like that are not made in a
>>> single day.
>>>
>>> Now what are you folks expecting? A full-fleshed out plan how to move? I
>>> think we should
>>> first decide IF we move and that was was happening here.
>> What I was expecting was decisions to be made on the basis of consensus.
>>
>> The vote was not for a trial with a single component nor was it for a
>> gradual move to git as components decided that they wanted to move. The
>> vote was for a very black and white proposal to move the entire of
>> Commons from svn to git.
>>
>> The vote did not get consensus - far from it with around a third of
>> those voting against the proposal. Therefore my objection was to the
>> statement in the vote result that "Apache Commons will be moving to Git
>> for SCM".
>>
>
> Why don't we side-step the consensus vs. majority and so on issue, and let
> whomever wants git propose to move one component and see how that goes?

+1
Phil
>
> Gary
>
>
>>> It was also pretty clear to start with a small step first and move a
>>> single component.
>>> If that would went wrong we could either go back without bigger loss or
>>> discuss what needs to be improved.
>> That is not what was stated in the vote. If it had been, I would have
>> voted +1. I indicated as much when I voted.
>>
>>> We are not using experimental bleeding edge technology here. We just
>>> wanted to decide if we will follow the git path or not.
>>>
>>> I really can't see anything bulldozed here.
>> The bulldozing was the statement "Apache Commons will be moving to Git
>> for SCM" when a significant proportion of the committers voted against
>> such a move.
>>
>>>> I have no objection to a switch to git for those components where there
>>>> is consensus to do so amongst the active developers.
>>>>
>>>> I continue to strongly recommend that a single component volunteers to
>>>> be the svn->git guinea pig for Commons and that we allow that component
>>>> to work out any issues that crop up before any mass switch starts. If
>>>> there are no issues, great. If there are issues, better to have to deal
>>>> with one set of them rather than 40+ sets.
>>> I have not understood it otherwise.
>>> Why did you start to believe we move all components at once?
>> The text of the vote, the text of the vote result and the context in
>> which the vote was conducted. At no point did the James (who was driving
>> this issue) make any statement that suggested (to me at least) anything
>> other than a wholesale migration from svn to git.
>>
>>>> Further, if the consensus amongst the active developers on a component
>>>> is that they wish to stick to svn, I see no why that component should be
>>>> forced to switch to git.
>>> I had the idea too and support it.
>> At this point I am unclear what support there is for what since folks
>> appear to have very different interpretations of exactly what was being
>> voted on.
>>
>> I think that there is consensus for a single component to trial the svn
>> to git migration to see how it goes. That approach certainly has my
>> support although I won't be volunteering any of the components I'm
>> working on - while I can see the advantages of git, the git mirrors give
>> me most of the advantages with none of the migration pain. I'm sure that
>> balance will change over time but personally I'm not there yet.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message