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

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

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