> As we rely more and more on the release criteria and addressing bugs > that are on the blocker list, I'm seeing a hesitation to fix any > other bugs in Branched. In some sense this is a good thing, less > change generally means more stability. >From a user and tester perspective, I'd like to speak up for the benefits of getting as many bug fixes as possible into a release. It wastes a considerable amount of time if people encounter, diagnose, and report bugs only to be told that they're already fixed. I'm also a bit concerned about the growing distance between the software people are running and the bleeding edge where bugs are easiest to fix. It creates additional complication when we have to discover and diagnose bugs in one version but then re-test for the same bugs in a newer version. If things are only fixed on the bleeding edge, it can also mean that the vast majority of users are always running a version of the software that's buggy, because fixes take 6-12 months to propagate into a supported version, but new releases will also have new features and thus new bugs which will not get fixed in that release. That said, I do understand the need to balance high bugfix thruput with stabilizing freezes and continual Rawhide development and testing. It seems to me that the standard for including bug fixes in Branched is (or should be) the same as for updates to the final release. That standard in practice seems to be fairly liberal post-release for non-critical packages - anything that's been tested and we're confident helps more than hurts. Of course critical path packages are held to higher standards, but in the end, it seems almost any suitably vetted bug fix would be "nice to have" in a milestone release. In terms of actual workflow, then, I see two classes of bugs - those that Release Engineering is monitoring closely around release time, and everything else. From what I hear, the first category includes both blockers and essentially non-blocking fixes you really want but which may or may not make it in time. Unless there's a good use case that would require two lists or a list plus flags, why not include both "hard" and "soft" blockers on a single monitoring list? I agree with Adam's leanings - after a blocker meeting determines a bug is a "soft" blocker, it's sufficient to indicate that in a comment on the bug. There's no real need for that attribute to be separately queryable, because for release preparation and scheduling purposes the whole list is gone through one by one. If you don't want to actively monitor a bug but do want to encourage the maintainer to get a fix in as soon as possible, I say the thing to do is to express that to them in a comment and then de-list the bug. As regular users and triagers, we have found that adding "F12Target" to a bug doesn't do anything more than asking nicely if something will be fixed in Fedora 12. Pretty much any bug will have a supporter who wishes it would get fixed in the current or next release, but setting keywords and severity appropriately and adding rationale in comments is probably a more nuanced and effective way to do that than adding to a special list. Lacking compelling motivation for more complexity, it probably makes sense in this case for Release Engineering to use the same mechanisms as everyone else, even though their requests and encouragement might carry more weight. -B. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
