On Tue, 2009-03-31 at 14:50 -0700, Adam Williamson wrote: > i) have reporters file separate bugs for each affected release that > someone cares about > ii) track all affected releases via one bug, using comments or > keywords There is also something of a hybrid approach we were discussing: keep one bug, until a fix is released. If a fix does not come out for a given release and someone wants to advocate for a backport, they can file a separate bug at that time. > The first proposal is that we simply use the same procedure (and > hence the same statuses and resolutions) for Fedora.... > The disadvantage of this is that the RHEL process is probably in > some ways over-engineered for Fedora: it uses several stages managed > by different teams which don't really exist so far as Fedora is > concerned, and relies on certain automatic steps which aren't, > AFAIK, actually automated for Fedora. Well, looking at this page: https://bugzilla.redhat.com/page.cgi?id=fields.html it seems that there are actually several states that RHEL doesn't use that Fedora does. Were there any other documents that we found that describe the RHEL process in detail? It might be nice to send out links to developers to say, "And for proposal #1, what Fedora would adopt would be based on *this*, after further discussion." The only automatic transitions are: MODIFIED -> ON_QA ON_QA -> RELEASE_PENDING RELEASE_PENDING -> CLOSED/ERRATA I think those are automated for supported Fedora releases, but not for Rawhide? Perhaps there is some room to improve automation so that Rawhide changes that are supposed to fix a certain bug automatically mark bugs CLOSED/RAWHIDE when the build gets released? In the meantime, it doesn't seem like a big downside to simply document that developers (or whoever) needs to do that manually. Two things that the above URL says aren't used in RHEL are "WORKSFORME" and "UPSTREAM". I guess I would have two questions to answer to clarify this page for Fedora use. 1.) Who decides when to set a bug CLOSED/UPSTREAM, and what are the criteria for doing so? And specifically, should triagers be expected to try to make this determination? 2.) Should WORKSFORME be banned? It seems that for RHEL, the correct answer is never "I tried it and it worked so there's probably not a bug". The alternative is to push reports back as NEEDINFO until they are resolved as NOTABUG (if it turns out to be user error) or CLOSED/RAWHIDE or the bug is isolated with the reporter's help. Usually these cases are either 1.) there is some local state (user configuration, hardware, etc.) that is triggering the bug or 2.) different people are testing different versions. Either way, further testing can resolve the question. "RAWHIDE" is also not used in RHEL. Conversely, the only state I see (correct me if I'm wrong) that's not used in Fedora is VERIFIED. The (entirely sensible) way you laid out the question was: "We can either 1.) use exactly the same procedure for RHEL and Fedora 2.) use a simplified version of RHEL for Fedora, or 3.) try to come up with something from scratch for Fedora." Based on the opinions expressed so far, I assume that there will be general agreement that making the two reasonably similar would be convenient. So the way I am thinking about the answer is: "What should the differences between Fedora and RHEL bug flow procedures be, if any?" The answer becomes clearer in my mind after seeing the actual concrete differences in current practices laid out. (Or at least the key decisions that will have to be made.) I don't know whether it's a good idea to get into details in the initial message to fedora-devel-list, but hopefully the discussion will output some concrete answers. -B. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
