I see that you disagree. Do you have an alternative or do you not recognise there is an issue and prefer the status quo?
I do find it offensive that you think my goal is to slow down GlassFish. Tbh I drove GlassFish through to Jakarta EE 9 compatibility from the initial donation. I thank you for picking up GlassFIsh for Jakarta EE 10 otherwise my team would
have had to do it again. You have done fantastic work.
However it needs to operate under the EDP and needs to give opportunities for open discussion. Otherwise, utlitmately, you will be left to do all the work yourselves if no one else can track what is going on without a large burden.
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).
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.
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.
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev