ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

On Thu, Mar 19, 2015 at 07:14:02PM +0000, Brendan Donegan wrote:
> Does this mean that it will not be possible for it to attain the QA
> sign-off needed status? Or would it be possible to get into that state
> before becoming dirty? I suppose it would but just checking

Having the same package in multiple silos at the same time is still allowed,
so it's certainly possible for a silo to be submitted for QA sign-off and
afterwards be marked as dirty.

The original intent of the train here was that conflicts would be detected
at silo assignment time, and the developers who were submitting silos in
parallel were expected to coordinate amongst themselves to decide which silo
takes precedence for landing, and which silo would be a "test" silo.  If
we're finding now that silos are being submitted for QA signoff when they
cannot (both) be landed, this is a failure of coordination.

The code change Robert has made to prevent known-dirty silos from being
submitted for QA is a useful safety net, but the train only "knows" which
silo is dirty fairly late in the game.  Landers need to take responsibility
for avoiding conflicting silos being submitted to QA.

Landers, please pay attention when the landing team tells you that your silo
has a conflict.  The trade-off from allowing liberal self-management of test
silos is that you *must* coordinate with your peers when there is a silo
conflict.  If we can't make this work in a way that doesn't waste the QA
team's time, then I think we should reconsider whether these kinds of test
silos should be allowed.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx


> On Thu, Mar 19, 2015 at 5:31 PM, Robert Park <robert.park@xxxxxxxxxxxxx>
> wrote:

> > Hi all,
> >
> > Just wanted to point out that CI Train has grown a new feature that
> > will hopefully reduce wasted man-hours:
> >
> > In the event that there are multiple silos containing the same
> > packages (which we call "conflicting silos"), and one of those silos
> > gets published, the other silos will now be marked as 'dirty',
> > indicating that the silo needs to be rebuilt.
> >
> > The 'dirty' status will appear in both the spreadsheet and the
> > dashboard, and it will look like "SILO DIRTY: You must rebuild: foo,
> > bar, grill".
> >
> > Rebuilds have always been required in this case, because if you were
> > to publish a dirty silo without rebuilding, it would effectively
> > revert the changes made by the other silo that published first. The
> > difference now is that you can actually see which silos are dirty as
> > soon as they become dirty, rather than having a nasty surprise at
> > publish-time.
> >
> > This is an important change because recently I've seen a number of
> > cases where a silo was dirty, but it went for QA anyway, QA spent many
> > hours verifying the silo, and then I published the silo only to
> > discover it had been dirty all along and all the QA effort was wasted.
> >
> > So, QA people, if you see a silo marked 'SILO DIRTY', stop QA'ing it!
> > it's a total and complete waste of your time to even look at a dirty
> > silo.
> >
> > Once a dirty silo is rebuilt, then the lander can resubmit it for QA.
> >
> > I hope people find this helpful! If you find any issues (with this
> > feature or with the train in general), please file bugs against
> > lp:cupstream2distro and assign them directly to me ('robru' on
> > launchpad and IRC).
> >
> > --
> > qa-team mailing list
> > qa-team@xxxxxxxxxxxxxxxxxxx
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/qa-team
> >

> -- 
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: Digital signature