Subject: Re: [PATCH] embargoed releases: also describe the git-security list and the process

From: Junio C Hamano <[email-masked]>
Date: Wed, 19 Oct 2022 08:47:13 -0700

Julia Ramer <[email-masked]> writes:

>> In this hypothetical timeline:
>>
>>     A---B-B-B-B-B-B-B-B---C
>>
>>               D0----E0           D1----E1 (next month)
>> ...
>> If the coordinated release C falls after the deadline D0 for the
>> upcoming "monthly security updates" (not singling out Microsoft by
> ...
> If I am understanding this particular scenario, I believe you intended:
>
> s/coordinated release C/final B/

Thanks for sharp eyes.  You're correct.  As long as the final B
comes before the deadline of a packager, then they should be able to
work within their own constraint.  If the final B comes after their
deadline, and they still want to include the fix in E0, then the
package needs to be "creative".

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

Exellent.  Thanks.