Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 98582 invoked from network); 30 Jan 2011 13:18:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Jan 2011 13:18:25 -0000 Received: (qmail 92516 invoked by uid 500); 30 Jan 2011 13:18:24 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 92318 invoked by uid 500); 30 Jan 2011 13:18:21 -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 92310 invoked by uid 99); 30 Jan 2011 13:18:20 -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 13:18:20 +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 13:18:14 +0000 Received: by wwa36 with SMTP id 36so4922086wwa.1 for ; Sun, 30 Jan 2011 05:17:54 -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=feqBsUbhqpw718x145Z+RV1EmG1pnMi+39OHkSJbkRw=; b=OjIY8G87hljQ0wGqL5PC8LCgSYpp1TLHLGeRuAdpAxpVa2L09UwE0n7OGeN9e4wUtN 80VnfCnWIJvVk29gjuN+J5tlnxIeht5rgDwmh3jJBPaaJetB/cERjnY5pHXS2cShuIcn eXmo+z8PNhXdkEih232hWj+Vr2oJ5DewMH50Y= 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=dbVlXir5e8VT2T5n+4xLpARUKoFHwCI4oz/tv54gEv/LWE8t7XFG7fE40B+qjfniNU om90CPOqTTh00sYsu3d34/eMWhUkcFH23JgAS0Q+18GPoDfIKZim4np1W4/E3eFlRl8I 1oriTYMTNhjzpY/lAKOEhUGuGlWjjGxg9EArw= MIME-Version: 1.0 Received: by 10.216.176.201 with SMTP id b51mr9727198wem.34.1296393473271; Sun, 30 Jan 2011 05:17:53 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.216.73.78 with HTTP; Sun, 30 Jan 2011 05:17:53 -0800 (PST) In-Reply-To: <4D44C030.2090103@apache.org> References: <4D443AF9.7070900@gmail.com> <4D44C030.2090103@apache.org> Date: Sun, 30 Jan 2011 15:17:53 +0200 X-Google-Sender-Auth: e0_k61Kr20BRleVmKHQkT3SBpfs Message-ID: Subject: Re: Trunk instability From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=0016363b9fba76a889049b1020e8 X-Virus-Checked: Checked by ClamAV on apache.org --0016363b9fba76a889049b1020e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reverting today is premature. Compiling is not an issue within the next hour or two. Passing the tests might take a day or two. On Sun, Jan 30, 2011 at 3:34 AM, Emmanuel L=E9charny = wrote: > On 1/29/11 10:20 PM, Alex Karasulu wrote: > >> Hi y'all, >> >> This trunk situation is just horrible. I don't know how I fell into >> working >> this heavily in the trunk. We all usually branch and work isolated. I in >> fact, I started refactoring in a branch. I don't know how this shifted >> into >> the trunk. It matters not though, so long as this never happens again. I >> sure am stressed over it and the time others are loosing. >> > It started with some good intentions : > - all the changes were supposed to be automatically impacting studio, the > API and ADS > - they were not supposed to be so heavy > - it was suppose to be done fast > - merging when many directories change is just a PITA to manage with SVN > > That being said, the initial changes leaded to some more changes, then so= me > others etc. It was an attempt to catch many birds with one stone. > > IMO, and I don't want to blame anyone on that, some really important rule= s > about development on a complex project have also been forgotten : > - trunk must build. Always. > - before starting to add new features, the previous one must be done > - when some task takes longer than expected, then usually we won't be abl= e > to finish it in time before being hit but our human physical limits > - big refactoring should start in a branch... > > On the bright side, we've got some great decoupling going on that will >> make >> life much easier, and the codec clearer, especially for use by those who >> will have to extend it for their own controls and extended operations. I >> prepared some hand written materials to share on these topics but we've >> been >> scrambling, trying to get this done fast. I'd like to prepare these >> materials formally after we stabilize. >> > The decoupling is a major step forward. If we had only focused on it, we > would have been done earlier. > > OTOH, using generics, creating a mechanism to allow codec injection, coul= d > have been done once the initial decoupling has been terminated. Working > using 'Sprints', or whatever we name them, is simply better than any othe= r > options we have when it's not an initial work. > > These changes are an important step even if we don't achieve full >> pluggability by M1 because it helps us clearly see what MUST be expose t= o >> users of the codec (API) and people extending the codec (SPI). We ain't >> gonna get fancy with OSGi either right now. Floating ideas on the ML is >> cool >> but right now we need this M1 out the door. My primary motive was to get >> the >> API roughly demarcated. This way huge shifts in the API between mileston= es >> don't have to happen. We don't want to freak users out. Our milestone >> contract gives us some liberty but maybe we should still try to be >> conservative with API changes. So that's why NOW is the best time to get >> this done fast before the M1. The rest of the milestone series should no= t >> have such massive API changes. >> > Totally agree. > > So let's just not panic about a day or two. (I say this because I am >> panicing) I will dedicate my time to get this done ASAP. We even talked >> about backing out etc with Emmanuel. But I think it would be an incredib= le >> loss at this point. We're going to have to do this at some point. Why no= t >> now and be done with it? Emmanuel the codec master is also equally >> involved. >> It takes a lot to change when things have settled over the past 6 years = in >> this shared area. But do realize, we have lots of tests, and most of the >> changes are not fundamental to the way the software works. The changes a= re >> high level structural changes. We have not changed the way we encode and >> decode, we've simply shifted exposed APIs. The new incongruities >> introduced >> will disappear fast and things will align again. We need to be confident >> in >> that. What worked before will work again. >> > I would say that : if tomorrow evening we don't get trunk back on rail, > compiling and tests passing, then I'll suggest to revert to something whi= ch > at least compile. I'm not even sure if we should not revert tomorrow > morning, create a branch, and finish what we are doing in the branch (the > cost of branching, reverting, and merging should be around 2 hours for on= e > person.) > > Let's see what tomorrow brings, and then we decide what to do. > > Thanks for the heads up, Alex > > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com > > --=20 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 --0016363b9fba76a889049b1020e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Reverting today is premature. =A0Compiling is not an issue within the next = hour or two. Passing the tests might take a day or two.=A0

On Sun, Jan 30, 2011 at 3:34 AM, Emmanuel= L=E9charny <e= lecharny@apache.org> wrote:
On 1/29/11 10:20 PM, Alex= Karasulu wrote:
Hi y'all,

This trunk situation is just horrible. I don't know how I fell into wor= king
this heavily in the trunk. We all usually branch and work isolated. I in fact, I started refactoring in a branch. I don't know how this shifted = into
the trunk. It matters not though, so long as this never happens again. I sure am stressed over it and the time others are loosing.
It started with some good intentions :
- all the changes were supposed to be automatically impacting studio, the A= PI and ADS
- they were not supposed to be so heavy
- it was suppose to be done fast
- merging when many directories change is just a PITA to manage with SVN
That being said, the initial changes leaded to some more changes, then some= others etc. It was an attempt to catch many birds with one stone.

IMO, and I don't want to blame anyone on that, some really important ru= les about development on a complex project have also been forgotten :
- trunk must build. Always.
- before starting to add new features, the previous one must be done
- when some task takes longer than expected, then usually we won't be a= ble to finish it in time before being hit but our human physical limits
- big refactoring should start in a branch...

On the bright side, we've got some great decoupling going on that will = make
life much easier, and the codec clearer, especially for use by those who will have to extend it for their own controls and extended operations. I prepared some hand written materials to share on these topics but we've= been
scrambling, trying to get this done fast. I'd like to prepare these
materials formally after we stabilize.
The decoupling is a major step forward. If we had only focused on it, we wo= uld have been done earlier.

OTOH, using generics, creating a mechanism to allow codec injection, could = have been done once the initial decoupling has been terminated. Working usi= ng 'Sprints', or whatever we name them, is simply better than any o= ther options we have when it's not an initial work.

These changes are an important step even if we don't achieve full
pluggability by M1 because it helps us clearly see what MUST be expose to users of the codec (API) and people extending the codec (SPI). We ain't=
gonna get fancy with OSGi either right now. Floating ideas on the ML is coo= l
but right now we need this M1 out the door. My primary motive was to get th= e
API roughly demarcated. This way huge shifts in the API between milestones<= br> don't have to happen. We don't want to freak users out. Our milesto= ne
contract gives us some liberty but maybe we should still try to be
conservative with API changes. So that's why NOW is the best time to ge= t
this done fast before the M1. The rest of the milestone series should not have such massive API changes.
Totally agree.

So let's just not panic about a day or two. (I say this because I am panicing) I will dedicate my time to get this done ASAP. We even talked
about backing out etc with Emmanuel. But I think it would be an incredible<= br> loss at this point. We're going to have to do this at some point. Why n= ot
now and be done with it? Emmanuel the codec master is also equally involved= .
It takes a lot to change when things have settled over the past 6 years in<= br> this shared area. But do realize, we have lots of tests, and most of the changes are not fundamental to the way the software works. The changes are<= br> high level structural changes. We have not changed the way we encode and decode, we've simply shifted exposed APIs. The new incongruities introd= uced
will disappear fast and things will align again. We need to be confident in=
that. What worked before will work again.
I would say that : if tomorrow evening we don't get trunk back on rail,= compiling and tests passing, then I'll suggest to revert to something = which at least compile. I'm not even sure if we should not revert tomor= row morning, create a branch, and finish what we are doing in the branch (t= he cost of branching, reverting, and merging should be around 2 hours for o= ne person.)

Let's see what tomorrow brings, and then we decide what to do.

Thanks for the heads up, Alex


--
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com




--
Alex Karasu= lu
My Blog :: http://www.j= roller.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
--0016363b9fba76a889049b1020e8--