[gnu.andrew at redhat.com: Re: OpenJDK 8u and Backport Bugs]

[Langer, Christoph]

Hi,

most of my comments have already been made in the other mail.

> > As for those two points: I can understand them - as specific
> > requirements for your workflow within your company, I guess. So to
> > solve these, I think it's ok to create backport items and track them.
> 
> That's the point. It shouldn't be a solution for one institution only.
> It should be a solution where people across different companies can
> participate and know who is doing what.
> 
> > However, it comes with the issues I described before so correctly
> > setting and double checking of the "fixed version" field before
> > pushing is required.
> 
> Yes. It would entail a bit more work for maintainers. To set the fix
> version accordingly (if it's not correct already). For 11u I don't
> anticipate this being a huge problem as 11-pool bugs get resolved
> properly on push.

As written in the other mail, I would then not use 11-pool but set the desired target version explicitly. This will avoid conflicts with Oracle backports as well as make life easier for maintainers who will only have to check whether the entered target is correct. Maintainers would then only need to modify target versions in case they change it explicitly for a reason.

> > Having that said, I still don't think that opening backport items in
> > advance should be the blueprint for contributors to the JDK updates
> > projects, as the 8u Wiki currently suggests. If at all, it should be
> > optional.
> 
> One issue I'd see with making this optional is that the entire proces
> falls short figuring out stale issues, knowing current assignees etc.

I don't think so. As a human when you check the backport status of the bug, you first look at linked backport items and then go through the comments. You'll easily see whether it was already backported, somebody is working on it (or not) or if the backport got stale because somebody claimed to be doing it and then went away.
The only valid point is that a machine generated report can only easily report on linked backport items. But I'm not sure whether this kind of reportability is worth mandating the effort of maintaining manual backport bugs for every single contributor while most of them won't be interested in such statistics. And at the end, when the backports are done, the traceable backport items will have been generated by hgupdater anyway. I can only see the benefit if inside your organization you want/need to track the work of backport assignees.

So, I still see the backport bugs only as optional, not a must.

Cheers
Christoph