backporting minor UI changes to keep QA scripts working

[Gervase Markham]

Frédéric Buclin wrote:
>> This means that, if you write a spiffy new test script to test something
>> that's never been tested before, you'll probably just write it for the
>> trunk. That's fine - Bugzilla's continually moving forward. And you can
>> use the time you would have spent backporting it to write another cool
>> test script.
> 
> Very funny. We are writing these tests for the first time, so we could
> hardly freeze together with the branch. What you say is to not test
> 2.20, at least using automated tests. 

That was my suggestion. It may turn out not to be practical, for the
very good reasons you've just given.

> 2.20 has been released ~ 3 months ago and will live for at least 2
> years. Everytime we want a new 2.20.x release, we will have to test it
> to make sure nothing is broken. And without these tests, this means
> doing the work manually again and again. Thanks a lot, but the QA team
> already did 3 such releases since July and we are very tired of doing
> this again and again... and it's very time consuming and require too
> many people (and I never got replies when asking help for QA stuff).

I understand entirely that it's unfair to load you down unnecessarily.
You are doing a great job.

How much changes are we actually making between 2.20.x releases? Are we
just doing security fixes, or is there still development going on?

> I'm trying to bring QA stuff out of the stone age, and for this, I
> require some tiny UI changes, read my previous message. If that's too
> much for you, by "freezing" the branch, I didn't know you were talking
> about zero Kelvin!

I think perhaps I didn't understand the level of UI change you were
talking about from Dave's original message. Sorry about that.

Gerv