On Wed, 2009-02-11 at 17:43 +0000, James Laska wrote: > > I'll also note that being head-down working on a bug and missing an IRC > > conversation is not that far off from being head-down working on a bug > > and missing an email that went by (: > > Agreed to both. This hits the nail on the head for me. I'd like to > spend some time outlining the inputs and outputs for Fedora QA during > the release process. > > What is expected of us, when is it expected? How will we communicate > status, where will these communications occur? When do we start > testing, where do we get our bits from, how do we know we're done? What > happens when the __it hits the fan? > > I don't think we should be pedantic about documenting the process ... > but making an effort here will pay off for all involved. Making the > process more transparent should invite outside contributions+input and I > guarantee will help identify soft spots where tooling or process changes > could simplify things. Reading this conversation on the list and various other places it's been going on, my input would be that the basic problem is there's a process which is not really honored here, creating friction on both sides. The BugZappers group is carefully maintaining a list of blocker bugs for each pre-release, as well as the final release. This list is then not really being honored. The fact that they don't always even get an explanation why not may be aggravating, but it's not really the important thing here. It seems to me that what really needs to happen is we - the people who actually have the power to decide when a release goes out, and the people who would like input into that process (man, I shouldn't have thrown away that fridge magnet or I'd know the terminology ;>) - need to decide on a process that will actually be honored by both sides. This could be as simple as just saying, well, we don't really want to bother with formal blocker lists for pre-releases (as is, practically speaking, the case at present). Pre-releases aren't stable. They're allowed to be broken. An informal "are there any real howlers? No? Let's go, then!" between a couple of people is enough. If everyone's happy with that, then that's fine, and the BugZappers can stop wasting time constructing blocker lists for pre-releases. Alternatively, we decide that we *do* want blocker lists for pre-releases, in which case those making the pre-releases have to honor them, which means either waiting until all the bugs on them are resolved or giving a proper explanation of why they're releasing without this happening. And we also specify who gets input into the blocker list. I would say that should be managed by the BugZappers, as they should be the group with the greatest ability to judge what issues are truly critical. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
