[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [glassfish-dev] Proposed Process for New Features, release plans post 7 Final
|
Hi Hiroki,
GlassFish (and other Jakarta EE
projects and even Payara) inherited extreme technical debt. I see
just Scott doing something with that on the TCK, and me on
GlassFish. Nearly every change means analyzing crazy amount of
code and trying to understand all consequences. That results in a
state that any new feature results in fixing old bugs along the
path, because everything is connected somehow. Or exactly opposite
- too many bugs can lead to a development of a new feature as a
replacement (GJULE).
It is clear that something must be
done, or whole JEE dies as obsoleted ineffective overcomplicated
pack of projects.
I have to oppose a bit - Alexander and
Piotrek (most active contributors of last weeks) are not from
OmniFish. OmniFish company was created in April 2022, before that
we (me, Arjan and Ondro) were just independent contributors and we
behave still the same. So this is not about any concentration o
power of any vendor, just this concrete vendor is very interested
in the quality of GlassFish, because we decided that after some
fixes and development is GlassFish worth of our support even on
production servers (and then we created the company). That is why
we invested much more than anyone else.
When I led a team of circa 10 people in
average working on a project of the size of GlassFish with so high
techdebt, it took nearly 10 years to comply with standards (along
with developing new features). Imagine that for JEE ... Luckily
the progress is not linear, each step is important and the
evolution never stops (while the product is useful for someone).
We are on a good path - but we can stop, not because of bias, but
rather because of lack of effectivity, if we would be pressured to
slow down too much so it would stop being effective for us.
I think that we can keep a rule that
any PR except really uncontroversial will not be merged in less
that two or three days, which would mean that
- it is fast enough
- anyone who is interested in GlassFish can do the review and
interact as a part of the team
- people are forced to watch what is happening on the project.
- if noone cares and review of the code is ok, even from
people from the same company, PR can be merged.
Your late reviews and my mistakes - I'm
not sure how you have found those mistakes. Most developers do
reviews just by reading the code, they don't even rebuild and try
it. Then such mistakes are usually discovered too late mostly in
released versions, but it's not so huge problem, they will be
fixed - but only if they are reported, that is the most important
part and I thank you for that. It would be good to write more unit
tests, but with so bad cohesion it is nearly impossible. But we
will get there, slowly ...
It is sure that when we try to fix
something or do some cleanup, we fix 8 bugs and create 1 (with the
opposite ratio it would be really bad). But GlassFish codebase is
"conserved" for more than 10 years in horrible state, I would call
this situation "refactor it now or forget it forever". So we
started. Btw I also remember some discussion when somebody
expected that GF would not be used as JEE10 "RI" (RI is not a term
any more, but we still need something to validate every TCK spec
with, so in practice RIs still do exist) because nobody wanted to
invest to it. Now it was used again to validate the TCK set and we
were finally able to keep the tempo. I have prepared yet one fix
for the TCK ...
So ... back to the basic idea - I
believe that if someone is interested in the project, he should
watch the GitHub repository and if he notices something
controversial, he should immediately comment it, for example.
"Give me a week, I have doubts, I need to try it first."
If he comes later, it is still alright,
we don't live isolated in a bunker and any change is not
definitive.
I believe that only this way we all can
do the best of we are able to do for GlassFish. And we need to
move fast with what is available.
About Microprofile - we can just vote
to keep it or to remove it or to give it a try and if it would
become evil, just remove it at some point in the future. But
remember that any change has consequences - we merged it with the
decision to maintain it. Removing it will have consequences too.
David.
On 09. 12. 22 7:09, Hiroki Sawamura
(Fujitsu) 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.
# 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
