Well,
The whole thing is starting with the question, how many code branches
(PR-s does not count here) are we willing to manage? Less branches less
maintenance overhead, less error prone. The minimal case: master +
freeze. That can be effective if the freeze time is sort enough. That's
1-2 days in the professional business, though we can allow 1-2 weeks,
maybe 3. Anything longer would be start to cause some pain.
Freeze times: 11.2, 11.3, 12.0, and 12.1 are 40, 36, 85, and 51 days
that's 212 days in a year. That's a lot.
So while the idea cutting the release branch out of master on the
expense of have a small freeze, however nice, elegant and simple, it
does not seem to work good enough.
I followed the RM works of Neil and Eric more or less closely during the
last few releases. They did an excellent job stewarding the PR-s towards
these releases. The problem is that this is an open source community
driven software we contribute whenever we find the time. That's a
constraint we have to live with.
As of the mentioned problems during the 9, 10, 11 cycle about the
diverging source code. I cannot speak of 9.0, but I only remember one
issue which required a rework of rather complicated change for the
release, and probably one changeset where we committed jars to the
repository accidentally and the removal of those jars was missing on the
release branch. While it caused some headaches especially for me, I did
not feel that difficult to manage those issues.
Let's see what options we have (in the following, a half managed branch
is managed for limited time):
1. manage one and a half branch master+ release branch: we do double
accounting on fixes which shall be required for the release during the
time between the cut of the release branch and the release.
2. manage one and two half branches: master + next + release. During
release period: next branch serves for integration. The master branch is
for fixes, and we also manage the release branch for release purposes as
we do right now.
3. manage multiple feature branches like php, javaee, etc. occasionally
merge them into master, master also serves for patches during release
and we manage a release branch as well. I have not thought this through,
but if someone does that, we can discuss that.
4. Maybe something else I have not though of ...
If we look at the details there are two cross repository commits per
release, that is the version change (with API signatures) on master and
the release branches. These changes are unique to their branches, they
can't be merged.
Neil proposed something like option number 2. Well, if we rename the
branches like master, release, releaseXYZ, then use master as
integration, release to add patches for the release, might occasionally
merged into master if required and have releaseXYZ rebased on release,
the we have the master unfreezed. We introduced another release branch
which have to be managed by the RM, however it can reduce the double
accounting between the master and release branches.
So it would look like:
(master) --(A)--(B)--(VM)--(D)-(M1)--(E)--(M2)--
(release) \--(C)---(F)---/----(G)---/
(releaseXYZ) \--(VR)
Where:
A, B, C, D, E, F, G are regular PR change commits,
M1, M2 are release -> master update merge commits
VM and VR are API version commits
In that way we do not have two roles for master branch. Though
committers needs to select their PR-s to the master/develop during
release times, (similar to master/next), master can be refreshed from
releases, and the actual releaseXYZ branch would always be the actual
release branct + the version change commit.
On 9/8/20 2:23 AM, Neil C Smith wrote:
Hi,
Moving discussion on this off the [NOTICE] tagged thread - those are
not meant to be too noisy ...
Laszlo made the following comments, which partly preempted my own
thoughts on the problems / durations of master freeze ... my further
thoughts below.
On Sun, 6 Sep 2020 at 20:22, Laszlo Kishalmi<laszlo.kisha...@gmail.com> wrote:
I think we shall revisit this code freeze on master process. this time
the freeze period was about 50 days that's more than the half of a
release timeline. If the freeze would take 1-2 occasionally 3 weeks that
could be Ok. We are having advanced version control tools in our hand,
let's use them. In order to prove my point, I'd volunteer being the RM
for 12.2.
There would be a feature freeze, but after the cut of the release branch
ad do the module version update, the master branch would be free for
merge. The PR-s patching the upcoming release will have a corresponding
PR for the master (or vice-versa). So yes there would be an overhead of
maintaining PR-s for two branches for a while, but at least it would
allow code be integrated and tested on master much longer.
I'm personally dubious about dropping master freeze itself. At least
without addressing all the reasons why it was there in the first
place, and all the discussions that led to it.
To all intents and purposes, master is our release branch. I remember
Eric and I discussing whether to use branches or just tags of master
for releases. As it is, we still have release branches more as a
technical detail and for post-release updates right now.
Master freezing wasn't originally my idea, but yes, I picked it out of
the original discussions (and there were a few +1s to doing so), for a
number of reasons. A key one IMO is that it means that at the start
of each release cycle, HEAD is literally at the previous release -
we're building on something that's been through some testing each
time. So, while we can do multiple PR for bringing fixes into the
release branch, there's a problem in a small number of cases where
master and release have diverged and so the fix isn't the same - we
had a number of issues recur between 9 -> 10 -> 11 because of that.
That the release branch is effectively cut from master at release date
rather than feature freeze is a positive?!
At the time we decided on the current release strategy, the problem of
master being frozen and holding up development was discussed quite a
bit. As were some ideas for addressing that. Personally, I'd prefer
we relooked at those first - master freezing itself isn't the issue,
it's what that is leading to in terms of development stalling.
PHP development has continued in a separate branch through master
freezes. I'd be interested in Junichi and others' thoughts on how
that has worked in practice? Why do we feel we need to unfreeze
master to have code integrated and tested?
One option we discussed last year was having a "next" branch through
freeze (in fact, looking back, a suggestion from Jan alongside
freeze!). ie. as soon as master freezes for release122, a next123
branch is cut. All PRs can be integrated and tested in that through
the freeze period, and then after release a PR created to merge
next123 to master, discussing and addressing any merge conflicts that
arise. Fixes go directly in master, but can be pulled into the next
branch if required. That way all new features get applied on top of
the previous release version.
Could that work? Does that address the concerns? Or do we need to
reverse the idea of master freeze and meet any concerns in other ways?
Either way we should discuss and then move via a lazy consensus thread
if necessary.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail:dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
