Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 62740 invoked from network); 30 Jan 2011 21:27:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Jan 2011 21:27:16 -0000 Received: (qmail 6060 invoked by uid 500); 30 Jan 2011 21:27:16 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 6000 invoked by uid 500); 30 Jan 2011 21:27:16 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 5988 invoked by uid 99); 30 Jan 2011 21:27:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Jan 2011 21:27:15 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Jan 2011 21:27:09 +0000 Received: by wwa36 with SMTP id 36so5186843wwa.1 for ; Sun, 30 Jan 2011 13:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=nhMPjTfJQeOGiu/Q0on5Cwv6PC0o0D4I/3+ymc9qLjk=; b=JKsXXUjMv3XA4cdYEXsqh3hr8VWxubT2UNkN5HopnhHG0jxRv0O9FCDzRefDDiXHY1 x3+2WySMfcaNvEAP7W2JV9grId86bBe5sRUrJxlhsxO87SVgdfgf6ETspYIujzfQhUD0 rPHwEfV0bfKtKxIgcgb8G/y47K7maNwcOHrkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=J4FIguhyN/8Ke4HVFi5WWBwG0ihdi44s20Xl4cMYi7HX6/4Cp0tW+Midve84DBuOrw AeNxtgsp6F1CcIEK0vD2FlrvLKyvGfBtFF5AlR6a1mjvpTA868DTQYuorSlvGSn6fzfc TIDNRiAmc/z6oMbg+8/CYnH3TEidMSEYcv5vI= MIME-Version: 1.0 Received: by 10.216.169.71 with SMTP id m49mr5445098wel.4.1296422807607; Sun, 30 Jan 2011 13:26:47 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.216.73.78 with HTTP; Sun, 30 Jan 2011 13:26:47 -0800 (PST) In-Reply-To: References: <4D45D3D2.7050409@gmail.com> Date: Sun, 30 Jan 2011 23:26:47 +0200 X-Google-Sender-Auth: HM3fAYUd8jMuticIYuVm72f6ZZU Message-ID: Subject: Re: Considering rolling back From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=0016367b664eed1a7f049b16f41f X-Virus-Checked: Checked by ClamAV on apache.org --0016367b664eed1a7f049b16f41f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 30, 2011 at 11:24 PM, Alex Karasulu wrote: > > > On Sun, Jan 30, 2011 at 11:10 PM, Emmanuel Lecharny 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 --0016367b664eed1a7f049b16f41f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 30, 2011 at 11:24 PM, Alex K= arasulu <akara= sulu@apache.org> wrote:


On Sun= , Jan 30, 2011 at 11:10 PM, Emmanuel Lecharny <elecharny@gmail.com&g= t; 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<= br> wasted on dealing with the complaints and ultimatums then solving the
problem. Instead we should work together and finish this. I'm open to a= ll
suggestions.
There is no ultimatum. There is just a need for all the committers to benef= it from a stable trunk, and if that means we branch, and revert in trunk, t= hen 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 dr= opped. 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 t= he 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. Someon= e
is telling me tonight or no go. Since when do we start bossing people aroun= d
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 rev= ert has to be done. And it's far more strong than an deadline. A deadli= ne 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 *techni= cally* 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 - b= efore 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 some= thing
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 ratio= nal and continue further and further in a mistake. Branching as suggested b= y Seelmann is far to be unreasonable, and will just cost one or two hours o= f *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, pr= obably because more changes than necessary were injected into trunk. The pr= oject is a big ship now, and changing one small part of it has impact on ma= ny 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 *befor= e* injecting such changes into the code base.

I'm not lecturing anyone here. We all perfectly know a community is wor= king. I just think that breaking such rules just introduces some breach bet= ween 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&#= 39;t understand. Damned if you do damned if you don't.=A0

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 po= int, 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 befor= e reverting. It's not automatic.=A0


And yes I am asking for a favor. Bear with me a lit= tle 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. =A0

--=
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
--0016367b664eed1a7f049b16f41f--