backport/SRU additional bugtasks require manual triage

I'm sorry, I can't make heads or tails of this. Can you please rephrase with the problem thats happening?

On 6 May 2011 07:09, Robert Collins <email address hidden> wrote:
> I'm sorry, I can't make heads or tails of this. Can you please rephrase
> with the problem thats happening?

The point is: if a bug is say Confirmed/High in bzr, and it is marked
as also affecting bzr-git, Kate feels it would be more reasonable for
the second task to default to Confirmed/High rather than New/Unknown.
Similarly with promoting from one series to the next.

So on that basis this would clearly interact very badly with the use case of speculatively adding products 'I think this affects foo' vs 'I'm a manager of foo as well as bar'. We might be able to do something more nuanced if we can understand the problem more - I'm leaving this incomplete till we can talk with Kate and get more info.

Thanks Martin, yes that is the sort of case - but I scoped this to the just the series and used the other bug to illustrate the one project to the other.

Robert, I'm not sure I understand why you think it would interact badly with speculatively adding products. I'm thinking this is for a specific package that may apply to multiple product series (ie. Lucid, Maverick ). By setting the defaults appropriately, it will bring it to the attention of the other team (and keep it on searches for that series... ;) ) Its easy enough for that person to go in and adjust the priority or status. If they disagree it is appropriate - Confirmed -> Invalid or Won't Fix. Similarily High -> Low is an easy enough transition - after the knowledgable person looks at it.

What happens by it being created as New/Undecided, is that when its a different team person, they don't see it on their radar. ie. there is a different set of kernel developers working on SRUs as opposed to those working on development.

I can pull examples out of https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-04-15, but there is also a similar type of report that will need to be generated for SRU releases.

Kate, the issue with speculatively adding new products is that many projects use the "New" status as their drive-to-zero inbox for incoming bugs. We sort of call this out on the web UI by having a quick link & count of the number of new bugs on the bugs page. If we change to set the status by default, we hurt that.

Rob, I suspect the more nuanced thing is that we should set the defaults using the permissions of the person adding the new task.

I wonder if this is different enough to bug 777853 to be separate.

Implementation-wise, they both together seem a simple change. Perhaps it's something we could try for a little bit?

Jono, the point about it being nuanced on the permissions of the person adding the task is a very good one. Certainly a developer of abc going in and saying "this also needs to be fixed in project xyz" is quite different than a user saying "I think this affects abc, xyz, jkl" - and should be treated differently.

I separated the series task creation defaults, from the package task creation defaults, since it seemed to be a different level of knowledge involved. For series tasks, if a developer of a package says this also affects series l,m,n - they know the code, and no further investigation should be required. Its not a new bug against the package, but rather an extending of scope of impact to other series. If a developer of a package "abc" says this also affects package "xyz" - they are likely to be right, but someone in "xyz" should assess. And knowing the priority of this problem from the other package's sense, makes it more likely to hit the radar for assessment, for those packages which have 100's of new bugs open against them all the time.

The reason the series aspect is a focus, is that the trend seems to be towards evolving teams dealing with stable releases (LTS, SRU's against past releases) vs. development.

So I think there are two issues here - one is that we make triage something that requires effort rather than being the default: we don't present the bug database in a way that facilities driving the new queue to zero. Secondly, *because* triage requires specific consideration, in any project with > 75 bugs, untriaged bugs quickly blow out of control.

If I understand the problem statement correctly, this can be described accurately as:
"backport/SRU additional bugtasks require manual triage"

with the assertion that something that is worth backporting/doing an SRU will usually have the same priority and importance as the original task.

This now makes a lot of sense to me and I'm going to update the description accordingly, please tell me if I got it wrong :)

Robert, yes I think you have it right. I agree with Kate that marking a bug as needing fixed in an earlier Ubuntu release (Nominate for series) it gets a bit fiddly. I suspect a lot of bugs that could be sru'd to the stable release don't get done just because it's a bit of a hassle to do all the widget poking.

However, note that I *think* if you solve bug #777861 that would largely obviate the need for doing this triage work to begin with.

Status changed to 'Confirmed' because the bug affects multiple users.

Ok, so bug 777861 is an apport thing that can be done whenever; if/when it is addressed we may want to drop this to 'low' (because of the obviated need for triaged per your comment #9)