[glassfish-dev] Proposed Process for New Features, release plans post 7

["Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>]

Hi,

 

I want to open a debate on a process for bringing new features in GlassFish given that it is the baseline for a number of vendor products.

Therefore I am suggesting that new features and dropping of significant features or baseline Java support are agreed by multiple stakeholders.

In principle I think new features should be described and agreed as part of a Release Plan before they are incorporated into the code base.

 

So early thoughts on a process;

 

1. For all new/dropped features or significant behaviour changes that a GitHub issue is created where the need for the feature can be described, debated and if need be voted on.
2. We label the issue with “New Feature” for a completely new feature; “Enhancement” for significant behaviour change; “Deprecation” for something to be removed.
3. That we have a set of planned future release milestones with agreed dates that can be used to label in which release one of these issues is targeted
4. That release planning is carried out asynch to agree the content of a feature release (Major/Minor)
5. When PRs are created implementing the feature that they mark that they “Fix” the referenced issue and receive approval from committers from different organisations and are open for some specified period of time to enable sufficient feedback.

 

Rationale: It has been raised to me as project lead (Note: not by Payara committers) that the incorporation of MicroProfile capabilities without planning, discussion and without suitable review has been problematic for some.

 

Second it is a necessary part of the EDP that; “Projects are required to make a Project plan available to their community at the beginning of the development cycle for each major and Minor Release.” Also “All major changes to Eclipse Projects must be announced and Reviewed by the Membership at Large. Major changes include the Project Phase transitions as well as the introduction or exclusion of significant new technology or capability.” So I think the above would satisfy that need in an area where we need to tighten up.

 

As a counterpoint I am comfortable with bug fixes entering the code base rapidly with approvers from the same org. Others can chime in if they disagree.

 

Thoughts?

 

 

Steve Millidge