On 6/15/20 1:01 AM, Korney Czukowski wrote:
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.
If you really wish, you can have the nightly UC right now just add the
following UC URL to your NetBeans:
https://builds.apache.org/job/netbeans-linux/lastSuccessfulBuild/artifact/nbbuild/nbms/updates.xml.gz
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
---------------------------------------------------------------------
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
