launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

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