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. > > 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
