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).
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.
- I have never seen voting against on any github repository.
- Labels are already used. We also use Milestones. As there is
not many developers, it doesn't bring too much value, except
release notes.
- 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?
- 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.
- 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;
- 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.
- We label the
issue with “New Feature” for a completely new feature;
“Enhancement” for significant behaviour change;
“Deprecation” for something to be removed.
- 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
- That release
planning is carried out asynch to agree the content of a
feature release (Major/Minor)
- 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