[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branching stable/2.22?

From: James Lowe
Subject: Re: branching stable/2.22?
Date: Fri, 11 Sep 2020 16:18:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 11/09/2020 15:22, David Kastrup wrote:
Jonas Hahnfeld <> writes:

Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
Here is my proposal for how to go ahead:

* we build a 2.21.6 from master, and announce it widely as a 2.22
pre-release version.
Adding Phil. I did a full test build of current master yesterday and it
worked fine with in place.
With respect to wording, every 2.21.x is some kind of pre-release for
2.22. If this proposal gets consensus, I'd emphasize that feature
development is over, but I'll leave that to native speakers 😉

* we institute a X week freeze; during the freeze, we only merge
   - fixes for regressions
   - updates to the documentation
   - cleanups with no functional changes, with little risk (ie. refrain
from build system changes, for example).
* after the X week freeze, if we still have open regressions, we tack
on another few weeks of freeze to fix them.
* if there are no regressions left, we branch stable/2.22, and release
a new pre-release.

X could be up for discussion, but 3 or 4 weeks seems long enough to
gather some feedback, but short enough that experimental/feature work
should not be affected.

The objective of the freeze is to focus developer energy on fixing
regressions rather than causing new regressions.
Sounds good to me.
To arrive at a decision, what do others think about this? Having a
large silent mass is not really helpful for this kind of discussion (as
it wasn't for the switch to GitLab).
Frankly I don't see the point in repeating points I already made and
call that "discussion".

I don't see that in the current stage of upheaval of both internals and
build system and infrastructure, there is a point in freezing off some
half-baked intermediate state that hasn't seen significant exposure to
extensive testing.

I cannot comment on 'Internals' but 'build system' and 'infrastructure' are not, I think, issues that really concern 'average Joe User' who wants to download and install a version of LP that works. That doesn't mean they don't matter but I don't see us getting all our proverbial waterfowl in a row any time soon with all the mix of MRs I am seeing of build/Infra and LP-specific. So we have to draw a line in the sand somewhere if only for those developers that just want to do 'build system and infrastructure' stuff so unless anything is broken 'now' for the build, why not just stop accepting any more MRs for it at this time?

In effect I agree with Jonas' plan but slightly modified, I suggest that unless anything is really broken with the build system 'today' (and I am not getting that vibe from the conversations I read) we have one more countdown for 'anything' build-related to get in the patch countdown and after that, we only focus on Regressions and docs, anything currently in the patch countdown that is build related gets counted down normally (if it gets pulled/needs more changes it cannot come back in) and eventually the countdown should only contain LP/Doc MRs and possibly even peter out to nothing which would be a good indicator of when to revisit a 'when shall we freeze'.

I don't do any development so feel a bit brash saying all this but personally I don't think we will need 'weeks' to decide a freeze date, I think it might become very obvious, very quickly once we prohibit build/infra MRs and focus on regressions/docs. And until someone 'says' an actual date - and gets feed back on that - I think we may keep on procrastinating.

As for 'extensive testing' well all that I can see we can do here I think is announce this to the user group and ask for help testing - even just running 'a build' on some big and/or complex scores and ask for feedback (perhaps put something on the website). I don't know what else we can do for testing.

Thanks for listening.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]