On Monday 25 January 2010 11:43:40 Jonathan Lange wrote: > On Thu, Jan 21, 2010 at 7:28 PM, Bjorn Tillenius <[email protected]> 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? _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
