Forgot the list, sorry. Début du message transféré :
> Expéditeur: Jean Abou Samra <j...@abou-samra.fr> > Date: 25 août 2020 14:43:21 UTC+2 > Destinataire: Jonas Hahnfeld <hah...@hahnjo.de> > Objet: Rép : branching stable/2.22? > > >> Le 25 août 2020 à 12:29, Jonas Hahnfeld <hah...@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 <hah...@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 >>>
