JDK Updates Project Page

[Rob McKenna]

Correcting a typo in Phil's address.

    -Rob

On 10/11/17 15:40, Rob McKenna wrote:
> 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