Julian Foad wrote on Fri, 01 May 2020 15:58 +0000:
> 1 May 2020 16:39:36 Nathan Hartman <hartman.nathan_at_gmail.com>:
>
> > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf < d.s_at_daniel.shahaf.name > wrote:
> >
> >
> > > danielsh_at_apache.org wrote on Thu, 30 Apr 2020 16:21 -0000:
> > >
> >
> > > I just copied the text we use for 1.9, but there's a distinction: users
> > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA,
> > > whereas users of 1.13 have not. So, should we promise some sort of
> > > grace period for users of 1.13.x — i.e., a period following the release
> > > of 1.14.0 during which we'll still fix security bugs in 1.13.0?
> >
> >
> > Before I can offer an opinion on that, I have to ask: If that
> > scenario actually occurs, where a security issue is discovered in a
> > release line very soon after it goes EOL,
… then there doesn't have to be a fix at all. By definition, once a line
goes EOL, we don't promise to fix bugs in it; the community's collective
stance on bugs becomes "Please upgrade to a supported release line".
Even then, people can still fix individual bugs in older lines, if
that's what scratches their personal itches. See r873205 for example.
That bug was found when only 1.4.x and 1.5.x were supported, but people
backported it all the way back to 1.0.x (!). We didn't roll a 1.0.x
release afterwards, but the fix was backported by us for downstream
packagers' benefit. This way, packagers don't have to resolve conflicts
by themselves and users don't have to contend with a minor version
upgrade (with the entailed risk of running into regressions,
particularly when upgrading to a .0 release).
Furthermore, we can choose to issue a fix even if we didn't promise to.
(The community's support promises are a minimum, not a maximum.) And
now, to your question:
> > does the fix have to be an actual *release* with all the process
> > that implies, or can it just be a (signed) patch?
Both.
When we have code we expect users to run, it's in our interest to issue
it as a proper release, in order for the legal shield to apply to it;
and I don't believe there's anything preventing us from releasing
unidiffs rather than (or alongside) compressed tarballs. We would still
have to vote on the unidiff, sign it, etc., just like any other release
artifact.
However, creating a release doesn't require using release.py, creating
tarballs, creating a tag, incrementing SVN_VER_PATCH, or holding the
vote on any particular mailing list. The hard minimum for a release is
a PMC vote that blesses a particular artifact as a release.
(By the way, that's one of the few cases in which the distinction
between "full committer" and "PMC member" matters. The former is
a community status, like "patch manager"; the latter is a legal
construct.)
> Re. issuing fixes as patches, I think there's no precedent and no
> grounds for doing so this time. The option of doing so in future for
> the general case should be raised in a separate thread.
Cheers,
Daniel
Received on 2020-05-01 23:11:09 CEST