[moving git-security@ to BCC; those who have been following the
thread, please switch to the main list]
> All of Junio's edits and call-outs are reasonable and I'll incorporate
> them into the next version.
Thanks.
>> > +- 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.
Thanks.
