launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Wed, Feb 24, 2010 at 05:06:23PM +0100, Danilo Šegan wrote:
> 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"

I should have added that I don't care much how this is implemented, I
just gave an example.


> 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,

Yes, I agree that Ursula should finish the tags-for-QA. It's not worth
implementing a system that works for both wiki and tags, when we're in
the process of getting rid of the wiki.


> and I'd have to ask you to add your request to the backlog (on
> "Translations" kanban board).

Sure, I could do that.

> 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.

I will certainly discuss this in more detail. This was just one thing
that I was quite sure was needed, so I though it would be better to get
things going already. I'm going to spend the next few days going over my
MergeWorklowDraft proposal and start defining things in more detail.
This will involve discussions with interested parties.

This got me thinking, how do we keep track of features involving
multiple teams using the Kanban boards?


-- 
Björn Tillenius | https://launchpad.net/~bjornt