directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Trunk instability
Date Sun, 30 Jan 2011 13:17:53 GMT
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├ęcharny <elecharny@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
>> 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 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 rules
> 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 able
> 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, could
> have been done once the initial decoupling has been terminated. Working
> using 'Sprints', or whatever we name them, is simply better than any other
> 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
>> 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 milestones
>> 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 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
>> loss at this point. We're going to have to do this at some point. Why not
>> 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 are
>> 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 which
> 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 one
> person.)
>
> Let's see what tomorrow brings, and then we decide what to do.
>
> Thanks for the heads up, Alex
>
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>


-- 
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