JDK Updates Project Page

[Rob McKenna]

Thanks for the feedback,

1) Moving to a single page makes sense, we can always split it up as
necessary if we end up adding to the process docs.

2) As David notes the bug approval process will be JBS only, no email
template involved.

3) We're sticking with the current codereview practices for a couple of
reasons:

  - Codereview is a contentious issue and out of scope for the updates
    project
  - Moving to JBS would limit participation to those with JBS logins
  - Reviewers are used to monitoring the appropriate email aliases,
    introducing a separate process for them to follow would introduce
    unnecessary complications

4) As noted in the approval page, the public codereview must be
completed prior to requesting critical approval.

5) We're setting a higher bar here for update release content. The
process page specifies P1 bugs & serious regressions. If a fix is not
critical then it can likely wait until the next feature release which will
be available within 6 months. (this has the added benefit of incentivizing
users to pick up JDK fixes faster)

6) As Phil noted, we're moving to a model where we no longer mandate
that backports need to be fixed in all releases between the next feature
and the backport release.

    -Rob

On 09/11/17 14:16, Mario Torre wrote:
> On Thu, Nov 9, 2017 at 1:43 PM, Mario Torre <neugens at redhat.com> wrote:
> 
> > Right, I see what you mean. It makes sense to have exclusively at JBS
> > based process. We will still need to ask for review via email, but I
> > think having a template for that may be overkill. Do we expect emails
> > on jdk-updates-dev to be anything but backport requests?
> 
> It now occurred to me that the process may be just done exclusively on
> JBS, including the review process:
> 
> 1. A developer wants to backport a fix from n+1 into n creates a
> backport request (marking the bug backport-request or whatever)
> 2. The bug is updated with links to the new webrev and all the
> information needed
> 3. The review happens on the bug tracking system. The Lead either
> approves the backport request or ask the original reviewer for review.
> 4. If the request is approve, the bug can be backported
> 5. Repeat for each backport version (perhaps is worth to create
> separate bugs for each backport)
> 
> Assuming that for 8 and 7 there is still the old process in place and
> that there is just one update-dev at any given time (two with the
> LTS), the process seems quite streamlined. It's not different than
> what is  being proposed, just happens on the bug tracking system and
> not on the mailing list, which is nice since it's easier to see the
> reasoning behind each bug and recreate its history.
> 
> What do you think, would that be of any help?
> 
> Cheers,
> Mario