Re: [glassfish-dev] Proposed Process for New Features, release plans pos

["Hiroki Sawamura (Fujitsu)" <sawamura.hiroki@xxxxxxxxxxx>]

Hi Steve,

I created the following proposal that summarized the ideas raised in mailing list and Slack for the PR process.
Could you review it and start the voting?

```
1) Create GitHub issue and describe the need for the new/dropped features or significant behaviour changes.
2) Label the issue with "New feature" for a completely new feature;
                        "enhancement" for significant behaviour change;
                        "deprecation" for something to be removed.
3) Create PR that references the issue, copy the above label to it from the issue, and defer merges for at least 24 hours for review by other committers.
  - If a PR is created without an issue, apply one of the above labels to it, and create a corresponding issue brefore review.
4) PR can be merged by any committer (including the proposer) after approved by committers from 2 different organisations.
  - If the PR is created by a committer, it's implicitly approved by their organisation, and only 1 more approval from a different organisation is required.
  - If no review or comment has been posted for 5 days, it can be merged with the approval of another committer of the same organization.
  - If there is any doubt, label "CONTROVERSY" as PR and continue the discussion.
    In this case, if there is no objection within 5 days of the last update by the proposer, the discussion is considered to be over.
* This process applies for new/dropped features or significant behaviour changes.
* Any PRs that do not meet the above conditions can be merged immediately by any committer (including the proposer) after 1 approved review by another committer.
  such as obvious bug fixes, refactoring/code cleaning, upgrading utility modules, adding tests.
```

Kind Regards,
Hiroki

-----Original Message-----
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Steve Millidge (Payara)
Sent: Friday, December 9, 2022 6:46 PM
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final

I agree Hiroki's comments below are a good balance;

“A PR can be merged by any committer (including the creator) after 1 approved review by another committer from a different organisation.”

Combined with 

" this is only for "add new features" and "change operating specs".
We shouldn't apply such rules to obvious "bug fixes" to slow down problem solving, I think."

We should also add a lazy consensus period whereby if there has been no review then same organisation can approve and merge. 

I will leave open to discussion for a while to hear from others. If can't get consensus I can kick off a vote.


Steve



-----Original Message-----
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Hiroki Sawamura (Fujitsu)
Sent: 09 December 2022 06:09
To: glassfish-dev@xxxxxxxxxxx
Subject: Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final

Hi,

Everyone knows Jakarta EE 10 would not have been released without the overwhelming contribution of Arjan and David and I’m also very grateful to you.

There seems to be misunderstanding and confusion.

I also don't think the current situation is healthy, where the work and responsibility is concentrated only on a particular vendor's engineers, even though there must be many other committers.

As Arjan and David say, there was enough time between when the Config API PR was created and when it was merged. I couldn't comment effectively, but I also watched the PR.
On the other hand, when we think that the PR has caught the eye of a lot of people or that it has been sufficiently discussed, we cannot explain it without a subjective measure of a period.

Steve has tried to set PR approval rules to the community in the past. This thread ends inconclusively, but I think we should discuss about it again.
--- https://www.eclipse.org/lists/glassfish-dev/msg00174.html
As a balance between speed and oversight I suggest this rule.

“A PR can be merged by any committer (including the creator) after 1 approved review by another committer from a different organisation.”
---

For example, set "min/max review period" or "min votes using a thumbs-up icon to PR to indicate consent [*]", "change assignments in turn so that reviewers are not biased", ... .
I believe that these rules may slow down the speed of development, but they will provide an opportunity for other committers to join the discussion.
I'd like to work together to find an effective means of doing so.

this is only for "add new features" and "change operating specs".
We shouldn't apply such rules to obvious "bug fixes" to slow down problem solving, I think.

# BTW, as for the positivity of the review, I'm at a bit of a disadvantage as I live on JST… # but I have also detected the following unintended behavior changes after approval during GF7 dev.(already fixed):
#   - https://github.com/eclipse-ee4j/grizzly/pull/2156#discussion_r891970471
#   - https://github.com/eclipse-ee4j/glassfish/pull/23973#discussion_r908028097

Kind Regards,
Hiroki

[*] GitHub doesn't seem to be able to duplicate an approve with multiple reviews. Anyway we might not to use the “approve” button for votes, which allows to merge PR immediately.


From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of David Matejcek
Sent: Friday, December 9, 2022 7:37 AM
To: glassfish-dev@xxxxxxxxxxx
Subject: Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final

Hi Steve,

When I was in Payara, I created an issue for any work needed (and asked others to do that) to have estimates and overall image about every work we plan to do in visible time or even in more distant future (with less detailed granularity). For Payara it makes sense, because Payara is a private company working on own controlled software.

GlassFish is different - it is completely open, so anyone, who has a spare time and good mood and especially good will, can create a pull request with a new feature or a bugfix. Then it depends on other contributors and especially on committers if there will be a discussion, some opposition or if active committers are happy with that and will merge it. There's always a step back possible.

Btw if you would ask why Andrew's PR wasn't merged asap, it was first because it did not pass the build, and later because I wanted to pass the TCK first, because I have found a blocker in combination with the TCK and I wanted to see all tests passing after my changes first. But it's alright, I am watching what is happening, so it didn't surprise me and didn't cause any harm.

This is not about committers and companies, but about people communicating together. And sometimes even arguing, no problem.

About Microprofile: as Arjan wrote, it was Matt's personal initiative, Arjan was happy for that, I was rather happy that Matt contributed GlassFish, but I'm not much involved in Microprofile integration except the "trick" to make GlassFish work on JDK11 too (with MP filtered out of the classpath). All this was discussed publicly on GitHub and very intensively also privately. Basically I agree that these things maybe should be planned before the impl, but on the other hand - prototype or some first attempt of integration has a value of gold. And it worked, so we agreed to merge it. I think that until now just only Rudy tried that, we were happy that someone tested it, despite he found an issue, but you know what I' saying - found bug is a good bug. It was fixed.

Yet one important note - if you want to plan something, you must have resources to do that. Since circa GlassFish 6.2, the most of the work was done by developers which later joined in OmniFish company and several other investors (because time and effort is an investment too, not just money). We passed the "full" TCK as the first implementation and that is a result of this organisation of work despite it may look chaotic from the outside. It is NOT chaotic at all, we just simply read all issues and all PRs, and someone of committers always responds. If there is something to discuss, it is discussed. You don't need to have an absolute control over everything when you have a good team.

I am quite proud we rescued GlassFish from the death ;-)

It has been raised to me as project lead that the incorporation of MicroProfile capabilities without planning, discussion and without suitable review has been problematic for some.

That is quite interesting, because nobody said a word against it for the whole long time while the PR was open and waiting for the verdict (and fixes). 
See https://github.com/eclipse-ee4j/glassfish/pull/23807
And https://github.com/eclipse-ee4j/glassfish/pull/23807#issuecomment-1075723424
And https://github.com/eclipse-ee4j/glassfish/pulls?q=helidon+

Yet another reason why the "theoretical process" won't work - basically currently there are just two core developers, me and Arjan. Arjan loves new features and always finds a way how to make it work. I love the maintenance, testing and improving things, and I too always find a way how to make it work. You know I have experiences with digging large piece of software out of the mud, cleaning it and making it usable how it always meant to be. It is a hard extremely complicated work, but when finally things are clean, shiny and nice, more effective, faster, smaller, more readable, useful ... aaah, that's nice, so nice. It will be a long painful journey to get GlassFish there. But I believe we can make it.

1. I have never seen voting against on any github repository.
2. Labels are already used. We also use Milestones. As there is not many developers, it doesn't bring too much value, except release notes.
3. Nope. This cannot work in next 10 years. First project doesn't "own" any GlassFish  developers, we are all volunteers. Nobody knows who will have time and when. Things are done when they are done, and are continuously discussed. Release date comes out of it, finally. It is hardly predictable, but flexible and more dynamic. Who would work on GF7, if me, Arjan, Piotrek, Ondro, Matt, Alexander and others wouldn't step in? Would it be usable or glued as usual just to pass the TCK?
4. Yeah, someone would agree the plan and that makes the plan done, right? I am sorry, now I'm starting to be bit sarcastic ... Btw nearly same way as GlassFish works the TCK. Plan remains just a plan when there's noone to work on it. And again - plans hardly work for volunteers when they mostly don't care about someone else's plans, but they have something to share, because it works for them and it looks generally useful for other people.
5. Honestly, this point is a bit offensive. It simply means that you don't believe the team. And even worse, it effectively means that you want GlassFish to slow down. Or to stop it's development. Btw usually PRs are waiting for some time, anyone can give his feedback.

David Matejcek.

On 08. 12. 22 19:52, Steve Millidge (Payara) wrote:
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 
 
 


_______________________________________________
glassfish-dev mailing list
mailto:glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev