Dear all,
Apache NetBeans 12. has finally out in the wild, so I think it is time
to revise our release process.
First of all, I would like you thank for the great job Eric did as
Release Manager during this long process. Thank you Eric!
These are my points below, it is not necessary complete, feel free to
extend and/or disagree.
So let's see what went good:
1. Well we did the release
2. It seems the automatic release build improvements worked good,
requiring much less manual effort from the RM to produce release
packages.
3. I felt that feedbacks coming from NetCAT were actually useful.
What needs to be improved:
1. Well before going into the details, a self reflection.
First and foremost:
Me need to be improved, not try to pushing through half baked PRs
which also brake the builds. Please forgive me that!
2. It took too long.
11.3-beta1: 01-29-2020, release announced: 03-05-2020: 36 days
The 12.0-beta1 branch had been cut on 16th of March, release
announced: 06-09-2020: 85 days
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.
Spending long time in the release window could discourage people
from contribution (might not be true, but it did that to me), lead
to piling up PRs.)
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?
4. NetCAT
While, as I mentioned, I've got useful feedback from them in JIRA. I
saw Geertjan an Jirka chasing around every once in a while and, if
work+life would have allowed that, I might even would have joined to
the Cause.
A summary and the community survey results should have been posted
before or soon after the announce. Probably it is just make it more
visible during LTS.
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.
How do I see we could improve:
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)
I'd interpret the LTS release as a polished version of 11.3. Get NetCAT
test that version back and forth. 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?). 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.
This would probably mean less development effort on the LTS, more can be
put into the LTS.1 release.
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.
Supporting the LTS with patches (I might be a bit carried away at this
point):
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.
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!
* I grew up in the communist block, where statements and discussions
were often interpreted as equivalent.