Bug 193772 - Would like MFC to reminders to move bugs to "Needs MFC" after timeout
Summary: Would like MFC to reminders to move bugs to "Needs MFC" after timeout
Status: Closed Overcome By Events
Alias: None
Product: Services
Classification: Unclassified
Component: Bug Tracker (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Bugmeister
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-19 14:54 UTC by Brooks Davis
Modified: 2017-12-17 07:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brooks Davis freebsd_committer 2014-09-19 14:54:36 UTC
For long timeouts due to risky changes or wanting to avoid releases in progress it would be nice if there was a state for "waiting for MFC timeout" with automation to move things to Needs MFC when the timeout expires (either through the MFC reminder script or a bugzilla field.  I think I prefer the latter if since it would let us differ an MFC.
Comment 1 Marcus von Appen freebsd_committer 2014-09-19 17:49:31 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?
Comment 2 Brooks Davis freebsd_committer 2014-09-19 19:13:38 UTC
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.
Comment 3 Marcus von Appen freebsd_committer 2014-09-19 20:53:02 UTC
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?
Comment 4 Brooks Davis freebsd_committer 2014-09-19 21:50:11 UTC
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.
Comment 5 Brooks Davis freebsd_committer 2017-10-15 18:54:22 UTC
https://mfc.kernelnomicon.org/6/ does a decent job of this.
Comment 6 vali gholami 2017-12-17 07:13:18 UTC
MARKED AS SPAM