[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-devel
Subject:    Fwd: branching stable/2.22?
From:       Jean Abou Samra <jean () abou-samra ! fr>
Date:       2020-08-25 12:45:49
Message-ID: E8DBD92C-1C1B-4591-8711-49867DAD6885 () abou-samra ! fr
[Download RAW message or body]

Forgot the list, sorry.

Début du message transféré :

> Expéditeur: Jean Abou Samra <jean@abou-samra.fr>
> Date: 25 août 2020 14:43:21 UTC+2
> Destinataire: Jonas Hahnfeld <hahnjo@hahnjo.de>
> Objet: Rép : branching stable/2.22?
> 
> 
> > 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 :
> > > > 
> > > > Am Montag, den 24.08.2020, 22:10 +0200 schrieb Jean Abou Samra:
> > > > > > > > > As sort of a shot in the dark, how about planning the 2.22 release \
> > > > > > > > > for May 2021, for example?
> > > > > > > > 
> > > > > > > > Do you mean branching stable/2.22 or releasing 2.22.0 in May 2021? In
> > > > > > > > my understanding, the past process includes the release of beta
> > > > > > > > versions from the branch. That makes it close to impossible to \
> > > > > > > > predict the final date of the stable version, and that's not the \
> > > > > > > > purpose of this thread.
> > > > > > > 
> > > > > > > I mean releasing 2.22.0 in May 2021. This is not about predictions, but \
> > > > > > > objectives. I think that instead of planning each small step on the fly \
> > > > > > > with no idea how the future looks like, we should settle an expected \
> > > > > > > date for the release and plan backwards accordingly. Sure, there could \
> > > > > > > be critical bugs that delay the actual release, but setting the \
> > > > > > > expectation enables more resources to focus on the release by the time \
> > > > > > > it is due to happen. In my opinion, this is the way we can avoid things \
> > > > > > > like the 2.14 release that is documented in the CG. 
> > > > > > > So, an expected release in May 2021 would mean branching release/2.20 \
> > > > > > > around January (?) and beta releases at a monthly cadence until the \
> > > > > > > release is out. 
> > > > > > > I'm curious about what others think of that. In fact it looks like you \
> > > > > > > already proposed something along these lines: \
> > > > > > > https://www.mail-archive.com/lilypond-devel@gnu.org/msg72997.html
> > > > > > 
> > > > > > And it didn't get much support. Which is why I don't see what's
> > > > > > different today. Asking what it would take to branch is really the only
> > > > > > sensible thing I think we could possibly agree on.
> > > > > 
> > > > > As I see it, you're asking something nobody, apparently, can give you. We \
> > > > > need to create the process instead of finding it out: what do you think it \
> > > > > should take to branch?
> > > > 
> > > > 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?
> 
> 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. 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.
> 
> Also, I value the actual date less than I value agreement on the date.
> 
> Best regards.
> Jean
> 
> 
> > > What I'm trying to convey here is that postponing decisions on the ground of \
> > > them being controversial is damaging to team members' morale. 
> > > To me, for the above-mentioned reasons, settling a date for branching 2.22 \
> > > amounts to scheduling the 2.22 release, which is why I think we should \
> > > explicitely discuss that schedule, instead of making short-term decisions that \
> > > only have consensus because the consequences weren't discussed, with no longer \
> > > term perspectives. The contrary would let the community split into small groups \
> > > of like-minded persons that avoid each other because don't want to go the \
> > > trouble of convincing each other. Given that you're ready to endorse the \
> > > release manager role and responsibility, I no longer see any blocker to \
> > > scheduling 2.20, except getting agreement about the schedule. 
> > > So we better start arguing about the schedule.
> > > 
> > > Cheers,
> > > Jean
> > > 


[prev in list] [next in list] [prev in thread] [next in thread]