[adding Veronica and Bri to TO:] On Wed, Sep 28, 2022 at 10:12 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > >> > +- Once the review has settled and everyone involved in the review agrees that > >> > + the patches are ready, the Git maintainer determines a release date as well > >> > >> s/maintainer determines/& and others determine/ or "stakeholders > >> discuss and agree on". You might want to mention that the schedule > >> for disclosure and release tend to be constrained by so called patch > >> Tuesday, which is the least flexible among various binary packagers. > > By the way, this "we account for patch Tuesday" is not "the only 800 > pound gorilla in the room inherently has rights to dictate their > terms". It is merely that "other packagers are being nice and extra > accomodating", and when another even less flexible packager requests > a prolonged schedule, we might accomodate their needs, depending on > the nature of the issue. > > On the other hand, the git users community may not be able to wait > for the next month to apply an unusually urgent fix, and a binary > packager with a coarse release granularity may have to be creative > on such an occasion. > > In this hypothetical timeline: > > A---B-B-B-B-B-B-B-B---C > > D0----E0 D1----E1 (next month) > > where > > A: problem reported > B: solution proposed, discussed, and finalized > C: public coordinated disclosure and release date > > Dn: cut-off date for "monthly security updates" for a packager > En: date "monthly security updates" is issued by a packager > > the wider Git user community may not be able to afford to wait until > date E1 of the next month by delaying C, even if date D0 for this > month's "security updates" for a particular packager comes before > the solution gets finalized. > > If the coordinated release C falls after the deadline D0 for the > upcoming "monthly security updates" (not singling out Microsoft by > mentioning "patch Tuesdays" anymore, as this applies generally to > anybody whose release granularity is more coarse than other distros > find comfortahble for security fixes) for a packager, but if an > early round of proposed fix is seen, they can independently make > their own judgement to include the non-final fix in their binary > release at their cut-off date D0, while withholding the source at > least to the agreed upon coordinate disclosure date C, for example. > If I am understanding this particular scenario, I believe you intended: s/coordinated release C/final B/ > They may later want to update to the final fix by date D1 to be > included in their next "monthly security updates" on date E1, which > would be an extra work, but that is the cost of running a coarse > release schedule. > > I do not know how to concisely phrase the above to fit in the > framework of your document, but some of the above issues were > brought up elsewhere, so I thought I'd better share it here. > I can take a stab at concisely phrasing this to fit within this framework, first paragraph for context, second is the addition: Once the review has settled and everyone involved in the review agrees that the patches are ready, the Git maintainer and others determine a release date as well as the release trains that are serviced. The decision regarding which versions need a backported fix is based on input from the reporter, the contributor who worked on the patches, and from stakeholders (e.g. operators of hosting sites who may want to analyze whether the given bug is exploited via any of the repositories they host). While the Git community does its best to accommodate the specific timeline requests of the various binary packagers, the nature of the issue may preclude a prolonged release schedule. For fixes deemed urgent, it may be in the best interest of the Git users community to shorten the disclosure and release timeline, and packagers may need to adapt accordingly.
