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

[Junio C Hamano <gitster@pobox.com>]

Julia Ramer <prplr@github.com> 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.