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/ [email protected] [email protected] > On Thu, Mar 19, 2015 at 5:31 PM, Robert Park <[email protected]> > 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 > > [email protected] > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/qa-team > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: Digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
