launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Fri, 2009-08-07 at 19:17 +0700, Stuart Bishop wrote:
> On Fri, Aug 7, 2009 at 5:06 PM, Danilo Šegan<danilo@xxxxxxxxxxxxx> wrote:
> 
> > У пет, 07. 08 2009. у 11:04 +0700, Stuart Bishop пише:
> >
> >> There are not 40 other revisions. A theoretical 0.14.1 -> 0.15 is not
> >> that big a leap.
> >
> > I must admit to not being completely comfortable with buildout setup for
> > core pieces like Storm, and I may have misunderstood all the version
> > names we use there.
> >
> > 2.2.7 branch versions.cfg mentions:
> >
> >  storm = 0.14salgado-storm-launchpad-288-308
> 
> On launchpad/devel:
> 
> storm = 0.14trunk-321
> 
> > I assumed that was storm 0.14 (rev 283 if I remember correctly) +
> > revisions 288 and 308.  Storm trunk is already at revision 324.  That's
> > 39 revisions we haven't seen yet in all parts of Launchpad.
> 
> > If I am mistaken, and 288-308 actually means all revisions between 288
> > and 308, including them, then it's only 19 revisions of changes to
> > Storm.  Much better, but still not perfect.
> 
> I don't know exactly what is in that branch - Salgado landed that one.

That branch had 0.14 plus revs 288 and 308; just that.

After some time we noticed the bug that r308 was supposed to fix was
not, so I submitted r319 to storm's trunk and we then cherry picked it
into production.

> 
> 
> >> I thought now was the perfect time to upgrade because we have two
> >> entire cycles on edge.
> >
> > Otherwise, it would have been.  But there are two more important things
> > we are doing right now:
> >
> >  * we are aiming for a major milestone 3.0, and we do want it well
> > tested with all the production parameters around them
> 
> Sure. So lets test it with 0.15 rather than some fork we have
> assembled ourselves. Lots of new UI code means lots of new database
> stuff too as lists get sorted differently, new reports are created,
> whole new searches implemented. Should all that new code be targeted
> at the Storm branch with the most bug fixes, or the branch that
> happens to have the bug fixes that have bitten us in the past?

I kind of agree with Stuart, but what concerns me are the scripts that
we only run on production -- these are not going to be tested against
0.15 until we roll 3.0 out.

> 
> >  * these 'two entire cycles' are supposed to be spent doing mostly UI,
> > meaning we should not have to devote engineers doing fixes for
> > incompatible Storm changes
> 
> You assuming there need to be changes for incompatible Storm changes.
> If there are incompatible Storm changes, we could make the decision on
> rolling back then. Your also assuming that our 0.14.x fork will
> somehow be less buggy are more stable than 0.15. I don't think that is
> the case, and we will be on our own if we tickle these bugs.
> 
> 
> >> We are currently running what will be one
> >> revision away from 0.15 on edge (some compile fixes for Windows need
> >> to land).
> >
> > A lot of the integration bits of Launchpad don't run on edge.  For
> > instance, we still would not have caught bug #408845 with this set-up,
> > since that happened in only <10% of our poimport script runs.

Agreed. ;)

> 
> That bug is an interesting one to cite - Salgado reported it last
> year. It is a bug that has been with us since the initial Storm
> migration I think - it is unrelated to Storm updates.

That's not true; I uncovered the bug when attempting to update our storm
branch to the latest trunk.  The version we used before 2.2.7 didn't
have that bug.

-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part