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