Re: branching stable/2.22?

[Jonas Hahnfeld]

Am Freitag, den 11.09.2020, 16:18 +0100 schrieb James Lowe:
> On 11/09/2020 15:22, David Kastrup wrote:
> > Jonas Hahnfeld <hahnjo@hahnjo.de> 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 https://github.com/gperciva/gub/pull/80 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

To keep things together, it was Han-Wen's proposal that I just happened
to quote. (My original question didn't have a freeze).

> 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.

Other than that, I fully agree with all you say (which was the reason I
didn't have a freeze initially and would have just picked whatever
necessary into the created branch, but that's off the table now).
Basically everything that gives an actable plan with consensus is fine
for me, I just want to avoid doing nothing until it's urgent.

Jonas

signature.asc
Description: This is a digitally signed message part