Hi all,
Let me add my 2 cents to the discussion:
You are aiming to be 'enterprise-friendly', so the release cycle,
feature freezes, NetCAT, etc all make very good sense. You should feel
free to adjust this process however it makes you more comfortable.
On the other hand, I'm sure a lot of people would be happy with having
nightly builds. Once a module is updated and published, it's downloaded
from the Update Center, like it used to. People who'll use this way of
getting updates won't have to wait up to half a year for a simple
improvement to be released. If a module released through this breaks
anything, it's not a big deal! It would be a polite thing for the change
author to fix it ASAP, but ideally (though not necessarily) if an update
could be 'recalled' and the updated modules downgraded in Update Center
until that time.
It should be possible to have both without too much of an extra effort!
This way, some early feedback could be acquired before the regular
release time and some issues already fixed, thus giving the enterprise
users potentially more stable releases to work with.
As for how to do it, unfortunately I don't know much of the history, so
it's very possible you've already discussed it at some point, in which
case accept my apologies for bringing this up again, but what's wrong
with having a 'living' master and 'frozen' release branches? Once you
create a release branch, it's effectively a feature-freeze, and from
this point, only necessary fixes should be merged into it. Why freeze
master as well? The master should still be considered 'stable', in a
sense that you're reasonable sure it's working and not breaking
anything. But if a fix for the release is needed due to something being
broken in master, it can be merged to both master and release, the PR
could be based on a point where the release branch has been created,
then no cherry-picking should be necessary and the merge history will be
preserved.
Regards.
13.06.2020 4:10, Laszlo Kishalmi wrote:
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.
---------------------------------------------------------------------
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
