On Fri, Aug 07, 2015 at 08:30:44AM -0400, Stephen Gallagher wrote: > It's very likely to get into "last blocker" discussions (as it did > yesterday). (By "last blocker" I mean those cases where the Go/No-Go > would tend to waive it as a blocker if it was the only one holding up a > release). To me, that means it's not really a blocker (and shouldn't be > classified as one). I'm not sure it should be dropped as a blocker. A lot of these things are here as a way of encoding institutional knowledge so that if someone was doing something we found to be important every release but then moves on to somethin else, it doesn't get forgotten. Maybe the release criteria aren't the best place for it, but we don't have much else which is a) global, b) well-documented, and c) has teeth. Making a non-blocker-but-checked state removes c, and while it theoretically keeps a and b, I'm kind of afraid that without c, the first ones fall by the wayside in the last-minute crunch. But, really, every time something gets into a last-minute crunch, we should evaluate how we can avoid that problem for the next release. (For example, with this cloud boot problem, the automated testing we're working on for two-week atomic will transfer directly to having much earlier warning about that kind of problem.) So, rather than dropping it as the first response, I think we should check if someone — from Design, presumably, possibly with the assistance of the maintainers of the backgrounds rpm; or else from the Workstation team — will put this on their schedule for next and future releases well before Alpha. If we can't find someone to do that, *then* weigh whether it is really important (and, if we decide it still is, look harder for the commitment). -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
