On Thu, Jan 21, 2010 at 12:31:13PM +0000, Julian Edwards wrote: > > Do you think it's acceptable that some parts of the UI might be totally > > un-usable? > > If the JS doesn't work then it should fall back to the plain pages, so I > wouldn't call that unusable. It may not fall back automatically of course, > but at least there *are* fallbacks.
Just like broken broken should fallback to something that works? I'm talking about the case where we don't know that that JS is broken. If we know it's broken, it's easy to fall back on something. But we certainly don't have anything in place that catches any JS errors, ensure that everything got hooked up properly, and undoes all the JS. I don't think such a foolproof system is possible. > > 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. 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. > I thought that having a separate JS buildbot was far better. The only thing > wrong was that we didn't have a process in place for someone to fix the test > failures when they happened. And we didn't have a process that stops the edge rollout (and production rollouts of course) when this happens, to avoid having broken UI being shipped to our users. I don't think a process that is non-blocking will work that well. And to be far, how many times have Windmill stopped the process? So far it's only stopped people from landing JS changes, which itself is bad, but there's only two people so far, and we kind of have a workaround (until we fix it). I'm not really counting your problem, since you're the only experiencing it, and you have the option to either use EC2 or not use xvfb, exluding the Windmill tests (if you're working on code that certainly isn't used in UI, which excludes Soyuz model code). > 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. It requires changes in our buildout setup. For example, I assume that some of the non-UI still would depend on other things in LP? That means that whenever the normal code base changes, the tests for the new code base would have to be run and possibly put us into testfix mode. Having a separate code base also means it's harder to move code between the code bases. I.e., having a separate causes quite a lot of complications, so we'll only do it if there are major gains. I'm still interested in a proposal how the new code base would look like. -- Björn Tillenius | https://launchpad.net/~bjornt _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
