launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 25 January 2010 11:43:40 Jonathan Lange wrote:
> On Thu, Jan 21, 2010 at 7:28 PM, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> 
wrote:
> > On Thu, Jan 21, 2010 at 12:31:13PM +0000, Julian Edwards wrote:
> 
> ...
> 
> >> > How do you propose we find all these issues that needs to be
> >> > fixed, before the tests "are aready"? The only issues so far is this
> >> > issue, which you are the only one to see, and the issue that Paul and
> >> > Tim reported. I'm looking at the latter now (which I hadn't seen
> >> > before, even though I ran the Windmill tests quite a lot), and I have
> >> > no way of reproducing your issue. How about we all ship and and make
> >> > the tests "ready", if they aren't already?
> >>
> >> My problem is that most of Soyuz has nothing to do with UI.  It's
> >> extremely frustrating to be unable to land a change to the buildd
> >> manager, for example, because some JS is failing.  I understand this is
> >> not exactly part of the "stop the line" ethos, but while we have these
> >> distinct parts that are not in the same line, it's bad for my blood
> >> pressure.
> 
> FWIW, I have absolutely no idea what "stop the line" even means in a
> distributed environment.

Me neither.  That's what I was intimating at with the comment about different 
lines.

> 
> > Well, sure I can see how that is frustrating. Just as frustrating for
> > non-Soyuz people that we're currently in testfix mode due to a failing
> > Soyuz test.
> 
> Perhaps the "in test fix mode" set up is simply the wrong fit for a
> distributed, busy environment like ours. Perhaps we should switch to
> something that works like PQM but is better, smarter & faster.
> 
> >> Perhaps I should consider splitting some of the non-UI Soyuz stuff into
> >> a separate code base?
> >
> > This might be an interesting thing to do. Not only for this issue, but
> > to make the test suite faster to run in the common case. If it's easy,
> > I'd like to see an example of how you would do it.
> >
> > Please note that your work may be thrown away, though, so don't do it
> > unless it's easy. If it's harder, try to explain how things work
> > instead. What would be included in the new package, and what depends on
> > what, for example.
> >
> > In general it's a lot of work doing all this, so it might not be worth
> > it.
> 
> [snip]
> 
> What are some things that will speed up our ability to land code and
> reduce its frustrations that are not a lot of work to do?

We *could* make buildbot advisory only.  That is, it says there's a failure 
but doesn't block landings.

As Bjorn pointed out as a corollary to what I said, Soyuz failures also block 
everyone else landing and I'll wager a bet that fewer people know how to fix 
those than I know how to fix non-Soyuz failures.  This is typical of a huge 
code base and it's only going to get worse.

In the past I've suggested we split LP up into separate projects, perhaps it's 
time to take another look?