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
