directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: Trunk instability
Date Sun, 30 Jan 2011 01:34:40 GMT
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


Mime
View raw message