launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi Bjorn, Ursula,

У сре, 24. 02 2010. у 15:28 +0200, Bjorn Tillenius пише:

> The script should tell us that r42 should be rolled out. The same is
> true if some of the revisions are bad:
> 
>     r41: OK
>     r42: OK
>     r43: BAD
>     r44: OK
>     r45: NEEDS QA
> 
> We will only roll out r44 after r43 has been marked as OK. so if we land
> a fix for r43 in r46, we might have something like this:
> 
>     r41: OK
>     r42: OK
>     r43: RCFIXED (r46)
>     r44: OK
>     r45: NEEDS QA
>     r46: OK
> 
> In the example above, r42 is still the revision to roll out, since r43
> should only be rolled out together with r46, which can't be rolled out
> wince r45 hasn't been QA yet.

I think this is needlessly complicated. What we need to achieve can be
simply achieved by landing everything up to the first 'NEEDS QA'/'BAD'.
Otherwise, we'd be asking of Ursula to implement a complicated graph
traversal algorithm that's very easy to break.

Everything else we can solve with one of several policies:
 1. use 'needs QA' until it's been QAd as "OK" (no use for 'BAD' then)
 2. switch from 'BAD' to 'RCFIXED' only once the RC revision and all
previous revisions have been QAd as "OK"

Both of these options provide a very simple algorithm, with very minimal
disadvantages compared to your proposal.

However, the more important question here is how do we keep track of
revisions and their QA statuses?  Remember that we are in the process of
switching to using tags for QA.

FWIW, Ursula is busy with implementing bits and pieces of tags-for-QA,
and I'd have to ask you to add your request to the backlog (on
"Translations" kanban board).  Also, considering this is part of a
bigger feature ("continuous QA"), I'd prefer if it was marked as such,
and if people like Ursula, Diogo, Gary and me were all engaged in the
design (because we are going to make sure it's delivered), or otherwise,
you are going to be randomly asking people to implement something for
what there might not be enough buy-in.

Cheers,
Danilo