Re: branching stable/2.22?

[Jonas Hahnfeld]

Am Dienstag, den 25.08.2020, 14:43 +0200 schrieb Jean Abou Samra:
> > Le 25 août 2020 à 12:29, Jonas Hahnfeld <hahnjo@hahnjo.de> a écrit :
> > 
> > Am Dienstag, den 25.08.2020, 12:06 +0200 schrieb Jean Abou Samra:
> > > > Le 25 août 2020 à 08:30, Jonas Hahnfeld <hahnjo@hahnjo.de> a écrit :
> > > > For me, creating the branch is nothing more than saying "feature
> > > > development is over and the current set is worth making stable". Which
> > > > I'm arguing is already there with Python 3 and the possibility to use
> > > > Guile 2. See my very initial message.
> > > 
> > > At the same time, you're saying that branching is not going to happen 
> > > next week. Please elaborate on your mind: when should that happen?
> > 
> > After below points have happened and after gathering agreement that
> > there are no open blockers to branching. IMO that would be something
> > fundamentally broken which can be expected to hit every user. AFAICT
> > that's not the case. Other problems can be addressed by picking fixes
> > into the branch.
> 
> That can happen in a week, can't it?

It could, but discussion takes time. Only because I don't see open
blockers doesn't mean it's true and others agree right away, as
evidenced here.

> I can't follow your mind anymore. You previously agreed with David that the 
> code base was in too much of a destabilized state for branching soon.

I said "in the next week" (note the singular form) which is basically
proven by this discussion. "soon" for me would be anything within the
next month.

> We're talking about bugs that we don't yet know but could pop up in the 
> months to come given this state.
> 
> > (It probably makes sense to branch right after making some future
> > unstable release, which implies that GUB is mostly happy, but that's
> > some minor detail I would say.)
> > 
> > > > On the administrative side, I think
> > > > * there should be another reformatting for all C++ and Scheme
> > > > * docs should be updated, including authors.itexi
> > > > Everything else can and should be picked as needed.
> > > 
> > > [...]
> > > 
> > > We're having, in fact, similar views. You say that we need to stabilize 
> > > the code base through branching, which I  entirely agree with -- except 
> > > that right now is not the right time.
> > 
> > So what objective function would you use to set an agreeable date? Just
> > time,
> 
> Yes, that is basically the idea. I think schedules help people work together 
> even if later deviated from.
> 
> > January 2021 being a shot in the dark?
> 
> Do speak up about what you would consider a more reasonable time.

I know I'll regret it because I still don't know what objective
criteria others have, but as you really insist on a statement:
in the week of 14th of September (this year, 2020, just to be clear)
or put differently: right after 2.21.7, from that very tag
As said before, I wouldn't make any commitment on the date of the final
release.

Now go off tearing me apart.

Jonas

> Also, I value the actual date less than I value agreement on the date.
> 
> Best regards.
> Jean

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