On 6/13/20 2:12 AM, Neil C Smith wrote:
Hi,
On Sat, 13 Jun 2020 at 03:10, Laszlo Kishalmi <[email protected]> wrote:
Apache NetBeans 12. has finally out in the wild, so I think it is time
to revise our release process.
Agreed! And thanks for kicking off. As discussed elsewhere, this is
something I had planned to do in the next week or two - it's something
we said we'd do now when agreeing the original schedule.
First of all, I would like you thank for the great job Eric did as
Release Manager during this long process. Thank you Eric!
+1 Many thanks Eric!
These are my points below, it is not necessary complete, feel free to
extend and/or disagree.
I'll add some comments inline - a lot I agree with, some I think we've
veered off a little from what we originally agreed on.
2. It seems the automatic release build improvements worked good,
requiring much less manual effort from the RM to produce release
packages.
Definitely! Thanks Eric (primarily) again.
Me need to be improved, not try to pushing through half baked PRs
which also brake the builds. Please forgive me that!
Or we need to prioritise having a testing process that's working and
accurate! It is easier as an RM, too, if you don't have to read CI
logs to work out whether a failing test is something that's failing
spuriously and needs retriggering until it goes green, or is an actual
problem that needs addressing.
The merge window was short as well. I know this is an LTS and NetCat
and everything, but seems having the master branch in release mode
for almost 3 months just does not seem to be right.
It did feel more of an issue this time around. Although we also
talked about having next / development branches to coalesce changes
during freezes - we've only, IIRC, done this with PHP around 11.1. If
there's a need that should be considered more, and might help with
backlog of pending feature PRs - with downside that merging after
freeze might become more complicated.
3. We need to think about what really LTS means for us.
* Is it a less feature more NetCAT release?
Right now this is what I think we think of that, but it is
probably too vague
* Is it just a rounded up version of the latest x.3 version?
* Are we plan to do some regular patches for an LTS or just
essential security updates?
Right now, the last one, but is it Ok that way?
It was intended to be all 3! I suggested based on two things - people
wanting to keep NetCAT in a quarterly schedule somehow, and people
concerned that updating every 3 months was too much for some education
/ corporate environments.
I think we need to review whether either of the assumptions that was
based on hold, and whether we should have an LTS at all!
5. Piling up PR-s. Well this is an issue on every release. PR-s are
reviewed and merged in a campaign base.
We need to somehow encourage PR-s to get actually merged.
I think this has become more of an issue recently - more below ...
We just cannot allow to have the master in feature freeze/release mode
for 6 months in a year (3x1 months for .x releases and 3 months for LTS)
Agreed. But I also think quarterly releases without freeze is not
feasible. Bear in mind the freeze period is meant to be concentrating
on stabilising what's been merged. If we can keep that to 1 month in
every 3 would that be good / better?!
Well the ~1 month freeze for the feature releases was ok. I would not
change that.
I'd interpret the LTS release as a polished version of 11.3. Get NetCAT
test that version back and forth.
That was the original intention, and kicking testing off on 11.3 was
also discussed originally, and I tried to suggest we do this again a
few months back.
Well, I was on different opinion back then. The 12.0 release changed my
mind. I'd rather see an LTS based on the testing and polishing the
latest feature release.
We going to get a number of bugs to be
ironed out through NetCAT and other sources for the LTS release.
Occasionally we can haggle for a feature creep if really needed (vote on
it?).
In 11.1 I did this via a lazy consensus thread for Payara and EE
stuff. Made a rod for my own back in doing so, mind you! :-) But I
think it's a good way to handle, but at RM discretion, because it's
they who it potentially makes the most work for.
In the light of that events. That's fine with me. Let the RM decide.
Having this, I'd not freeze the master for LTS. Let it have its
separate branch and separate life cycle. Fixes needed for LTS would
first go into master and have a twin PR for the LTS branch as well.
To review, one of the reasons for freeze is that having master and
release branch in sync makes it possible to have identical fixes in
both - the more they diverge, the more likelihood that things behave
differently, and the more likelihood that the fix in the next release
isn't as stable as the previous one. I think we had problems between
9 and 10 like this, where the same issues recurred in 10?
Well, it might happened, maybe due to human error (me). However as far
as I remember, there were generally no problem cherry picking changes
from the master, though I had to request a new pr to the release branch
as the code started to diverge. It was around the new update
functionality required for supporting nb-javac and javaFX module installs...
We could stop having LTS, and I am rather inclined to do so - we could
leave it to third-party distributors to offer longer support /
backport critical fixes? We could still have next .0 be the release
after NetCAT on .3.
Well, I do not know, I'd probably open a separate discussion on that
topic. As of my personal needs, I've made my perfect distribution with
netbeans-dev Snap package. But seeing the stats of the netbeans snap, we
just got ~1000 users of 11.0 LTS in the middle of April 2020 out of the
blue, before the number of LTS users were below 100. The total number of
snap users is between 21000-22000 in these months. Well overall. these
numbers says nothing more, but that it seems to have a need for an LTS
release.
Leaving that job for third party distributors? I have mixed feelings,
especially after the clash with legal on GPL+CPE license on installers.
I'd suggest, let's wait how far this retro goes, and if you see fit,
kick a separate discussion/voting on not having an LTS.
If we keep LTS, we could have a month freeze again, then vote on a
release candidate. We could have a month of that in the wild, with
critical fixes on release branch and pushed via UC, while master is
reopened for next release. Note, voting on a release candidate would
also allow us to share more publicly (not that Geertjan doesn't
already share the beta links widely! ;-) )
I'm not sure I understand this correctly, but: Let's do a 12.0 on master
like a regular feature release. but bring it just to beta release, then
release patches via UC. and once we think it is ready for release, do
another full release for voting and finally release that one (assuming
that it passed the voting round)?
Interesting idea. I'd see how easily we can utilize our UC in such a
process first though.
On the PR-s. We should agree on a default merge policy. Something like:
If not stated otherwise, PRs with the following conditions shall be merged:
* The CI checks are green
* No pending change request review.
* No labels against merge (work-in-progress, do-not-merge, etc.
* No open questions in the comments
* One of the following conditions fulfilled:
o All reviewer approved
o One reviewer approved and at least 3 days old
o At least 7 days old
Anyone who has commit rights are entitled and encouraged to do the merge.
Outside of freezes I agree with that, if by a committer. If opened by
a non-committer we need to check more carefully authorship / IP, maybe
require review. (Noting that a contributor does not, in general,
require an ICLA - planning a thread on that).
It is for non-freeze time only. I meant the "not stated otherwise" as
there is no announced restrictions on the master branch, like freeze,
major reorganization or whatever else...
Lets add to the conditions on first place:
* The PR author is a commiter
Inside of freezes, I'd like to keep (go back?) to the RM being the
only person who merges. However, that is purely about scheduling.
I'd really like to see us get back to a regular weekly beta during
freezes - the RM being in charge of merging, checking the tests, and
if necessary reverting is key to having timely betas (based on
experience, not opinion!)
In freezes, the RM shall be in charge. I support that only the RM can
merge in those times.
Anything that met the above criteria, was labelled for release, and
ready to merge by weekly beta cutoff, was merged during 11.1 and 11.2
- hence disagreement on the piling up PRs comment above! A general
principle of, if the PR is ready to merge on Monday, it's in the beta
on Wednesday (or whatever days suit the RM) is something I'd
personally like to make a documented part of the release process.
Go for it, document it. Generally I like the idea of being more time
based. On the other hand we are still a bunch of people doing most of
the work in our free time, so I'm bit skeptic on that, but we never know
if we won't even try it.
During the release phase of a feature release we could select a few
bugfixes for a patch release which we can carry back to the LTS branch
and produce a patch release, probably a few weeks / a month after the
feature release. Of course if we have resources for that.
Actually, whether we have an LTS or not, I'd suggest it's pushing
critical fixes between release dates that's more important?!
"?!" What would that mean here?
Phew, this is what I have on my mind now. Remember this is a not a
statement, it is a discussion*. Feel free to join!
Really useful! Hopefully comments don't seem too opposing - just
concentrated on where my view differs a bit.
Thanks and best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
