You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2020/06/13 02:10:10 UTC
[DISCUSS] NetBeans 12.0 Retrospective
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.
RE: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Eric Barboni <sk...@apache.org>.
Hi,
Thanks for the thanks, but lots of people a helping.
I cannot comment every point but I wan't just put emphase on the PR review.
PR review should be green,
but if red we should remove the warning that make RM/PR reviewer take 15mins to dig what is wrong. (If not internet issue with repository)
For me, on approval, if a reviewer say yes and if there is an open question that shoudn't be possible. It should be unapprouved to me until question is answered. A RM is not necessarily knowing each face of NetBeans and know the impact of open question. (Different of request for change). I cannot remember how many time I asked it it's ok to be merged because of unclear comment.
For beta and dev build,
We have maven snapshots that's all restricted access to people who can connect to snapshot repos (commiter I guess).
Can we use our netbeans-vm for that, with restricted access ?
More sensitive,
We should have a way to publish our native code (launcher, platform launcher,.. ) in a ASF way, sources + vote if we need to improve them. Maybe we should create another repo to handle that and maven can help. (because releasing with maven is 2 command line + vote )
On documentation
We release installer, Apache NetBeans, Html4j, vscode and all the small utilities, snap package we should have dedicated triage page for RM to refer to. It was too short from 11.3 to 12.0 for me to handle that. But I would like to consolidate this point.
Regards
Eric
-----Message d'origine-----
De : Neil C Smith <ne...@apache.org>
Envoyé : lundi 15 juin 2020 11:11
À : dev <de...@netbeans.apache.org>
Objet : Re: [DISCUSS] NetBeans 12.0 Retrospective
Couple of quick responses, and then let other people respond :-) ...
On Sat, 13 Jun 2020 at 17:59, Laszlo Kishalmi <la...@gmail.com> wrote:
> On 6/13/20 2:12 AM, Neil C Smith wrote:
> > 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,
No, nothing to do with you - there were a few times I remember noticing things that were fixed in release branches were not properly fixed in master because by the time of the fix they'd diverged. ie.
bugs fixed in 9 were not as well fixed in master before 10. To me, it's the linear history, that next release builds on the previous release, that's most useful about freeze.
> > We could stop having LTS,
>
> Well, I do not know, I'd probably open a separate discussion on that
> topic.
Yes, maybe, let's see where this goes - the question of why we have one and what it is keeps coming up. Of course, answering the latter might help with the former.
> > If we keep LTS, we could have a month freeze again, then vote on a
> > release candidate.
> 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)?
Yes, that's pretty much what I meant (and badly described)! I'd call it release candidate though.
Currently we have betas that are not voted on and distributed direct from the build. Theoretically, under ASF rules those links should not go beyond dev@.
A release candidate that was properly voted on and distributed via mirrors could be much more widely publicised.
> > 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.
Yes, personally I find it easier to block out a regular slot in the diary for the free time stuff than to pick it up piecemeal, so that's why I did it that way. I realise that we're all in different work / free time scenarios so it might not work for everyone.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Neil C Smith <ne...@apache.org>.
Couple of quick responses, and then let other people respond :-) ...
On Sat, 13 Jun 2020 at 17:59, Laszlo Kishalmi <la...@gmail.com> wrote:
> On 6/13/20 2:12 AM, Neil C Smith wrote:
> > 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,
No, nothing to do with you - there were a few times I remember
noticing things that were fixed in release branches were not properly
fixed in master because by the time of the fix they'd diverged. ie.
bugs fixed in 9 were not as well fixed in master before 10. To me,
it's the linear history, that next release builds on the previous
release, that's most useful about freeze.
> > We could stop having LTS,
>
> Well, I do not know, I'd probably open a separate discussion on that
> topic.
Yes, maybe, let's see where this goes - the question of why we have
one and what it is keeps coming up. Of course, answering the latter
might help with the former.
> > If we keep LTS, we could have a month freeze again, then vote on a
> > release candidate.
> 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)?
Yes, that's pretty much what I meant (and badly described)! I'd call
it release candidate though.
Currently we have betas that are not voted on and distributed direct
from the build. Theoretically, under ASF rules those links should not
go beyond dev@.
A release candidate that was properly voted on and distributed via
mirrors could be much more widely publicised.
> > 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.
Yes, personally I find it easier to block out a regular slot in the
diary for the free time stuff than to pick it up piecemeal, so that's
why I did it that way. I realise that we're all in different work /
free time scenarios so it might not work for everyone.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 6/13/20 2:12 AM, Neil C Smith wrote:
> Hi,
>
> On Sat, 13 Jun 2020 at 03:10, Laszlo Kishalmi <la...@gmail.com> 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Sat, 13 Jun 2020 at 03:10, Laszlo Kishalmi <la...@gmail.com> 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?!
> 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.
>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.
> 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?
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.
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! ;-) )
> 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).
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!)
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.
> 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?!
> 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Korney Czukowski <cz...@seznam.cz>.
You may be right about the stupidities, but this is how things work in
life :)
Though you may have had it sounded somewhat worse than it really is, the
project might be over by being completed and deployed and hopefully
doing some good to somebody, and most of the developers switched to
another one. Or the development could have moved to an area where
there's no longer a need to use a hypothetical NetBeans feature that is
currently lacking. It might still be needed again for the next project,
or not, depending on what's to come. By 'over' I meant from the
developers participation perspective and what their roles are within a
project.
Plugin could have been good, but a lot of functionality is already in
NetBeans, so should I invent a plug-in that's nearly identical in what
it does, just to be able to update it faster?
16.06.2020 20:22, Matthias Bläsing wrote:
> Hi,
>
> Am Dienstag, den 16.06.2020, 11:08 +0200 schrieb Korney Czukowski:
>> My argument is that some areas of software development, especially
>> related to web, can be very rapid, for example, by the time a
>> poorly-timed submission of an improvement of some NetBeans functionality
>> is accepted and released, a project whose developers could benefit from
>> it might be over.
> I would say, that this is non-feature for NetBeans.
>
> To be frank: This is one of the main stupidities of web-development.
> Everybody think he invented the next hot shit, for a few
> hours/days/weeks many agree and then the next hot shit comes. This is
> throw away development.
>
> If you want that: create a plugin and distribute it via the plugin
> portal. Your done, as you rightly said: The feature might not survive
> long enough to even get into the netbeans core.
>
> Greetings
>
> Matthias
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Dienstag, den 16.06.2020, 11:08 +0200 schrieb Korney Czukowski:
> My argument is that some areas of software development, especially
> related to web, can be very rapid, for example, by the time a
> poorly-timed submission of an improvement of some NetBeans functionality
> is accepted and released, a project whose developers could benefit from
> it might be over.
I would say, that this is non-feature for NetBeans.
To be frank: This is one of the main stupidities of web-development.
Everybody think he invented the next hot shit, for a few
hours/days/weeks many agree and then the next hot shit comes. This is
throw away development.
If you want that: create a plugin and distribute it via the plugin
portal. Your done, as you rightly said: The feature might not survive
long enough to even get into the netbeans core.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Korney Czukowski <cz...@seznam.cz>.
Thanks for the links! I've started reading the linked threads, but it'll
take some time before I finish.
I have an idea of how you do it currently, and now that I realized this
time you've tried a new thing to see if it'll work better, I'm looking
forward to seeing a discussion about the results. In the mean time I'll
try to find some arguments for and against different approaches in the
archived threads.
I also think a discussion should be held whether releasing updates just
as they become available can be beneficial to NetBeans and if so,
whether it is a worthwhile goal to pursue.
My argument is that some areas of software development, especially
related to web, can be very rapid, for example, by the time a
poorly-timed submission of an improvement of some NetBeans functionality
is accepted and released, a project whose developers could benefit from
it might be over. If some form of rapid releases was available, it could
motivate developers to contribute more to NetBeans itself, which in turn
might attract more users. But that would require to clear this somehow
with ASF, if it's only for dev@ list subscribers, then a few users would
gladly use it, sure, probably myself among them, but I'm not sure if
it'll be really worth all the trouble.
15.06.2020 11:32, Neil C Smith wrote:
> On Mon, 15 Jun 2020 at 09:01, Korney Czukowski <cz...@seznam.cz> wrote:
>> 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.
> Doing that for dev builds again should hopefully be on the horizon.
> But that would be purely for people on the dev@ list here - as a wider
> mechanism I'm not sure we could do that in line with ASF release
> processes.
>
>> 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?
> For the history, if you want to read, there is
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule
> https://cwiki.apache.org/confluence/display/NETBEANS/Notes+and+Discussions+on+the+Release+Schedule
>
> and the linked to mailing list threads.
>
> We do have a living master, we don't really (except in name) have
> release branches - at first there were some small differences but now
> they are exactly in sync until the moment of release - master is
> always what is intended for the next release, be that in 3 months or 3
> days time. We did do as you mentioned prior to 11.1. The change was
> to simplify the release process to make quarterly releases manageable,
> and to help make sure next release always builds on previous release.
> Whether we stick with that is open to debate - we said we'd review
> after a full cycle (ie. now).
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 15 Jun 2020 at 09:01, Korney Czukowski <cz...@seznam.cz> wrote:
> 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.
Doing that for dev builds again should hopefully be on the horizon.
But that would be purely for people on the dev@ list here - as a wider
mechanism I'm not sure we could do that in line with ASF release
processes.
> 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?
For the history, if you want to read, there is
https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule
https://cwiki.apache.org/confluence/display/NETBEANS/Notes+and+Discussions+on+the+Release+Schedule
and the linked to mailing list threads.
We do have a living master, we don't really (except in name) have
release branches - at first there were some small differences but now
they are exactly in sync until the moment of release - master is
always what is intended for the next release, be that in 3 months or 3
days time. We did do as you mentioned prior to 11.1. The change was
to simplify the release process to make quarterly releases manageable,
and to help make sure next release always builds on previous release.
Whether we stick with that is open to debate - we said we'd review
after a full cycle (ie. now).
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Laszlo Kishalmi <la...@gmail.com>.
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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] NetBeans 12.0 Retrospective
Posted by Korney Czukowski <cz...@seznam.cz>.
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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists