Bug 193772
| Summary: | Would like MFC to reminders to move bugs to "Needs MFC" after timeout | ||
|---|---|---|---|
| Product: | Services | Reporter: | Brooks Davis <brooks> |
| Component: | Bug Tracker | Assignee: | Bugmeister <bugmeister> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | tablosazi.farahan |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Brooks Davis
2014-09-19 14:54:36 UTC
Can you please explain in greater detail, what kind of functionality you want? I'm not sure, I understand, what you ask for. * What is the issue you have right now with Needs MFC? * What would you like to be able to do with a bug? * What is the expected outcome, if your requirements are * satisfied? * not satisfied? Right now when I commit a fix that should be MFC'd my choices are to leave the bug in the old state (and get no reminders), mark it as fixed (wrong), or mark it needs mfc. The latter is fine for things with a short timeout because I'll get a reminder email around the right time most of the time. For things that won't be ready to MFC for months, weekly reminder emails are suboptimal as I have to remember if I'm ready to MFC the item in question. Ideally I'd like a way to trigger a move to Needs MFC at some point in the future. Then I would get an email about the change and the weekly emails would only reflect things that are actually in my MFC queue. It's still too vague for me. From what I understand, you have two use cases: a) fixes that must be MFCd and can be committed quickly b) fixes that must be MFCd and can't be committed quickly 1) due to heavy dependencies that need to be MFCd first 2) due to a release process For a), the current approach is sufficient for you, if I get you right. For b) however, you'd like to have a sort of scheduler, which allows you to move the bug to be MFCd whenever pending requirements are fulfilled. Is that correct? If this is the case, a correct approach for b.1) could be dependent bugs. Those serve as blockers, which do not "allow" you to MFC until they are resolved. As soon as all blockers are resolved, the bug of type b.2) would become a bug of type a). b.2) would need more information about the target version for the MFC process. Side note: We're currently refactoring the status model and Needs MFC is a status to be dropped, since it' far too unspecific. Instead we plan to set it as flag, ideally tailored to target relevant versions. This may give you a better control about when to be reminded about MFCs, aside from the general weekly reminder. Does that sound sufficient (in theory :-). Do you feel something missing? I think dependent bugs could solve b.1 and b.2 (for b.2 a bug of "ship 10.1-RELEASE" could be created). There's also b.3) This change is high risk so it needs to sit in HEAD for a month or two to ensure sufficient testing. Most of those things aren't actually bugs, but some probably are. https://mfc.kernelnomicon.org/6/ does a decent job of this. MARKED AS SPAM |