directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Considering rolling back
Date Sun, 30 Jan 2011 21:26:47 GMT
On Sun, Jan 30, 2011 at 11:24 PM, Alex Karasulu <akarasulu@apache.org>wrote:

>
>
> On Sun, Jan 30, 2011 at 11:10 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:
>
>> On 1/30/11 9:15 PM, Alex Karasulu wrote:
>>
>>> STATUS
>>> -------------
>>>
>>> All the projects should now compile. I am going through all the tests now
>>> and will be re-applying Emmanuel's commits some of which were lost on a
>>> merge conflict. After Emmanuel's changes, I will fix some of the issues
>>> Stefan Seelmann discovered with the Control instances, and start making
>>> the
>>> tests work again.
>>>
>>>
>>> ROLLING BACK
>>> ------------------------
>>>
>>> It seems people want to rollback the recent changes. There's more time
>>> wasted on dealing with the complaints and ultimatums then solving the
>>> problem. Instead we should work together and finish this. I'm open to all
>>> suggestions.
>>>
>> There is no ultimatum. There is just a need for all the committers to
>> benefit from a stable trunk, and if that means we branch, and revert in
>> trunk, then it's probably the best move. We can't continue forever to work
>> on a broken trunk, it's blocking everyone.
>>
>> Now, that does not mean either that what have been done so far should be
>> dropped. As Stefan proposed, it's just a matter to copy the current trunk in
>> a branch, revert to some stable version in trunk, and continue fixing the
>> branch until it's stable again. Then we can merge back the branch in trunk.
>>
>>  Furthermore there should be no deadline imposed on anyone by anyone.
>>> Someone
>>> is telling me tonight or no go. Since when do we start bossing people
>>> around
>>> on this project? However I do understand this situation must improve soon
>>> and will roll back myself if need be. Reason should prevail not panic.
>>>
>> As soon as someone pushes a -1 on all the changes that broke trunk, the
>> revert has to be done. And it's far more strong than an deadline. A deadline
>> is really a limit fixed to avoid such a -1 to be pushed.
>>
>> Anyone can -1 anyone commits assuming it's technically grounded, it's not
>> "bossing people". And a broken trunk for a week is *technically* grounded.
>> Giving some more time with a deadline is doing a favor to those who have
>> broken the trunk, expecting them to fix it - or rollback - before a revert
>> is requested.
>>
>>  I am making progress but if others are worried then, any progress in
>>> *code*
>>> is no progress to the community. We have SVN and can go back to earlier
>>> states any time we choose.
>>>
>>> However can someone rationally inform me why we're so rushed?
>>>
>> Just because it's now one full week the trunk is unstable.
>>
>>  Is a couple days going to make or break something I am unaware of?
>>>
>>> I spent a lot of energy on this and it will result in many positive
>>> consequences. However I am reluctant to continue if there will be social
>>> uneasiness. So I will keep trying fully dedicated to this and we can see
>>> where we are in the short term.
>>>
>>> If this is not salvageable, then we can just move the current trunks into
>>> branches, and place an older stable version of the trunk where trunk is
>>> now.
>>>
>>> There's no reason to get angry, or argue. A mistake was made doing
>>> something
>>> this big in the trunk. People are on it full time trying to fix it. There
>>> are ways to roll out too. We're not going to die here folks.
>>>
>> No, we aren't going to die. But there is also no reason to not be rational
>> and continue further and further in a mistake. Branching as suggested by
>> Seelmann is far to be unreasonable, and will just cost one or two hours of
>> *one* person in the project, allowing all the others to go on.
>>
>> We broke one rule, by breaking trunk. This breakage lasted way too long,
>> probably because more changes than necessary were injected into trunk. The
>> project is a big ship now, and changing one small part of it has impact on
>> many other part, now think about what can happen when more than one change
>> is done. I don't think it's too far pushing the ball to ask for some kind of
>> stability between changes, and also some discussion to occur *before*
>> injecting such changes into the code base.
>>
>> I'm not lecturing anyone here. We all perfectly know a community is
>> working. I just think that breaking such rules just introduces some breach
>> between members in this community and this is not good.
>>
>>
> If you remember I said let me create a branch for this. You said don't
> worry about it. I don't understand. Damned if you do damned if you don't.
>
> You were involved in this so it's not just my fault compadre. Let's just
> push this to completion together. And yes Stefan made a reasonable point,
> and if I had you here on IRC we could foreseeably be done with this in the
> next day. Hopefully by tonight.
>
> Oh and on a -1 there will need to be a discussion before reverting. It's
> not automatic.
>
>
And yes I am asking for a favor. Bear with me a little guys. Emmanuel I
waited in my BRANCH doing this stuff while you did not want me to mess up a
merge for your AP work.

I am expecting the same civility.

-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message