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
