Bug 7080

Summary:	Allow bugs to target multiple milestones
Product:	[Infrastructure] Bugzilla	Reporter:	Michael Halstead <mhalstead>
Component:	bugzilla	Assignee:	Michael Halstead <mhalstead>
Status:	RESOLVED OBSOLETE	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	infras.bug.watcher, Infras.watcher, randy.macleod, richard.purdie, sjolley.yp.pm
Version:	unspecified
Target Milestone:	Future
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)
Bug Depends on:	9677
Bug Blocks:

Description Michael Halstead 2014-12-12 21:33:39 UTC

Currently we have no good way to indicate that a bug needs to be backported to previous versions. We need to be able to track this.

Ideally Bugzilla would allow us to select multiple milestones but this is not currently possible. Work is being done to allow this functionality but it is targeting Bugzilla 5.x. I don't think we will be able to move to 5.x for quite awhile after it is released due to Testopia.

So how to other groups handle this? The main way is to clone the main bug and assign the clone to the new milestone while making the clone dependant on and linked to the main bug. This works well for some groups but it does mean you need to look in multiple bugs for the full set of information about a single bug. This would probably be more normal feeling to new contributors.

We could also handle this as we have the Doc Changes needed. A field called "backport required" could indicate that after the bug is fixed in the current version it needs to be resigned to a different milestone rather than closed. This is probably the most natural for our existing users since they are already aware of the Doc Change workflow.

Comment 1 Richard Purdie 2014-12-18 15:35:29 UTC

We don't want to start duplicating bugs so I think this needs to be one of the other two options.

Comment 2 Michael Halstead 2015-01-12 21:46:23 UTC

Shall I proceed with adding the "backport required" field?

Comment 3 Richard Purdie 2015-01-22 14:49:05 UTC

Michael: Yes please, I think this is going to be the best way forward.

Comment 4 Richard Purdie 2016-12-14 17:45:16 UTC

Talking with Michael we probably need a pair of fields, "Backport Required:" and "Backport Applied:", this means we can flag which releases need a backport and when those backports are applied.

Comment 5 Michael Halstead 2023-03-13 17:02:07 UTC

Since adding LTS maintenance the workflow has changed enough this bug is obsolete.