Re: branching stable/2.22?

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

James