Hi,
- online meeting
Good idea, but... how about using Jakarta EE's Slack[*]?
[*] https://join.slack.com/t/eclipsefoundationhq/
I'm very sorry, but online meeting interactions are costly in terms of translation in my brain, making it difficult to discuss effectively...
using a chat tool like Slack, I'll be able to post more effectively because the conversation remains as text.
I think there is also an advantage that there is no need to take the minutes again:)
Kind regards,
Hiroki
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Steve Millidge (Payara)
Sent: Friday, December 9, 2022 11:02 PM
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final
Personally I prefer asynch working but I am not against a meeting if others want to.
I would still like to set rules on PR merges in the manner Hiroki suggests. I don’t think there is bad feeling but if people feel excluded or are not able to keep on top of reviews they will just drift away from the project and you will be left alone.
I am co-project lead therefore I have a responsibility to ensure the smooth running in accordance with the EDP.
Steve Millidge
From: glassfish-dev <mailto:glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of David Matejcek
Sent: 09 December 2022 13:41
To: mailto:glassfish-dev@xxxxxxxxxxx
Subject: Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final
Hi,
for OmniFish we have yet one idea - what about periodical online meeting where we would show where we are and where we go, what all of us would like to do, etc?
Current CET time is 14, so in Japan is 22, right? So let's say, every first Thursday in a month at 8 GMT?
That could reduce bad feelings too.
Maybe I "sounded" too angry, but I just want to have clear and loud agreement of everyone in the team reducing future stress of everyone.
Microprofile - yeah, that is why we approved it, it is rather a border case. While it is easy to remove it if things would go wrong, it is alright. Also - until now we released just milestones, and I think just two of milestones made it to Maven Central. So if we agree that we should remove it, we still can.
About approvals - we can create some shiny label CONTROVERSY, so if any reviewer would have doubts and required discussion over some change, he would just mark the PR.
What do you think, Steve?
David.
On 09. 12. 22 14:13, Hiroki Sawamura (Fujitsu) wrote:
Hi Arjan,
Thank you for your like.
As you can see from my PRs, I always request from at least 4 orgs, eg OmniFish, Payara, Oracle and Gold/pzy (individuals). Unfortunately some of those never respond, which makes requesting them more of a procedural “requirement” instead of an actual benefit of any kind to the project.
Yes..., the Jakarta EE community is growing now, but the reality is that there is still a shortage of engineers, and several engineers are responsible for the development of many projects, which means that they do not have enough time for reviews, I think...
However, I expect that such people will be able to adjust their time more easily if a clear deadline is set.
Would it help you (and other interested parties) if we remove MP from the base distribution again, and then create an additional distribution of GF that does contain MP?
Hmm... IMHO, MP is fine as it is now if it is only referenced by the web class loader and there are no licensing issues. when we want to use it for GlassFish's core impl, we need to be more careful.
# I was hoping that MP would be like "Java Cloud Edition" and that each specification would be separately pluggable into Java SE or Jakarta EE. But that didn't match MP's development stance and sounded difficult...
Kind regards,
Hiroki
From: glassfish-dev mailto:glassfish-dev-bounces@xxxxxxxxxxx On Behalf Of arjan tijms
Sent: Friday, December 9, 2022 9:00 PM
To: glassfish developer discussions mailto:glassfish-dev@xxxxxxxxxxx
Subject: Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final
Hi,
Thanks for your view on this topic. See response online below:
On Friday, December 9, 2022, Hiroki Sawamura (Fujitsu) mailto:sawamura.hiroki@xxxxxxxxxxx wrote:
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.
Yes, that seems entirely reasonable. Fujitsu has been helpful in reviewing before, and taking the JST / CET differences into account a one or two day minimum would probably be a good rule. Eg have a min/max of 1/7 or 2/5 or so (these are just suggestions).
Like you, I do hope too we can get some more activity from the other committers in GF. It would be a petty if at the end of the day the rule changes nothing but delay merging.
As you can see from my PRs, I always request from at least 4 orgs, eg OmniFish, Payara, Oracle and Gold/pzy (individuals). Unfortunately some of those never respond, which makes requesting them more of a procedural “requirement” instead of an actual benefit of any kind to the project.
On the very specific topic of MicroProfile, I agree with you that the situation is not ideal. It’s for that reason I started many discussions to try to address some of the disconnect between EE and MP, but as MP is quite conservative and slow moving, change is seemingly not easy there.
Would it help you (and other interested parties) if we remove MP from the base distribution again, and then create an additional distribution of GF that does contain MP?
Kind regards,
Arjan Tijms
# 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 mailto:glassfish-dev-bounces@xxxxxxxxxxx On Behalf Of David Matejcek
Sent: Friday, December 9, 2022 7:37 AM
To: mailto: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:mailto:glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
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
mailto:glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
