launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

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.

>
> 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?

jml