launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

(This is a repackaged version of an excerpt from the weekly yellow 
postmortem minutes I sent to the list earlier today.  If you've read 
that email, you've read the meat of this.  Responding to this mail for 
this topic might be easier for everyone to follow.)

Yellow squad recently had to change the zope.testing egg in order to 
address bug 609986.  We've used a patched/forked zope.testing egg in 
Launchpad for close to two years now.  Our work represents the fifth 
"release" of our fork.

Moreover, the forked zope.testing egg that we have been using had many 
tests that failed, and changes to the fork that were not tested.  After 
work by yellow squad, the version landing today (p5) only has three 
tests that fail [*], but > 0 is a problem because it makes further 
changes to the egg (like the ones we did) difficult.  The lack of tests 
for the forked changes also proved challenging, because we needed to 
change the changes a bit.  We added tests for our work.

We made some observations, and have some suggested process changes. 
First, the observations.

 * Forking code means that you take responsibility for it, within the 
context of your project.  This includes passing tests, and tests for 
your changes.  Generally, forks hurt more than you think they will.
 * Patching (and patched eggs) is equivalent in that regard; and worse 
because subsequent developers do not have a branch to work with.
 * Doing a constant upgrade to your dependencies is the right thing to 
do in general, as advocated recently by someone on canonical-tech.  It's 
like brushing your teeth: if you don't do it, things rot, and it's a lot 
more expensive to fix later.  However, we acknowledged that it can be a 
very expensive regular process too--perhaps more expensive in aggregate.
 * We are far behind on zope eggs.  Catching up will be expensive, and 
it is difficult to be motivated given the low activity/participation of 
that project.
 * Contributing work upstream is difficult when you have a fork.  It's 
especially difficult if you are far behind trunk.  It's even more 
difficult if you are not motivated because the upstream is dead or dying.

Here are our suggested process changes.

 * For future projects (e.g. SOA stand-alone projects) explicitly adopt 
a constant-upgrade (or at least regularly-scheduled-upgrade) dependency 
policy, setting up expectations and schedules initially.
 * Never patch eggs; fork branches if you must, and make eggs from them.
 * If you fork, make sure tests pass on branch before you leave, and in 
general take ownership of the code.  Acknowledge that you are making a 
new package.

We don't intend to make any further immediate changes to Launchpad or 
zope.testing because of these observations, even though there are many 
obvious further steps we could take.

Gary


[*] We fixed some test failures, and disabled some others.