-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 15, 2007, at 12:55 AM, Martin v. Löwis wrote:
> I don't think I can be more plain than that: yes, I do not take
> security
> seriously enough to release security fixes for old Python versions
> more
> than once a year. As a user, it's easy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 14, 2007, at 7:19 PM, Martin v. Löwis wrote:
>> Still, I'm in agreement with you that the repository holds the
>> security
>> patches and that the tarballs are a convenience. They are an
>> important
>> convenience though, so I would say t
> You can always can make a checkout of the security-manteined-only
> branch, if you're in a particular hurry (maybe the PEP should say
> something about this).
Indeed. I can add explicit wording to say that.
Regards,
Martin
___
Python-Dev mailing list
> | I think we would need to restrict the total number of releases
> | made per year. The one-year limit may be debatable, and immediate
> | releases might be possible, as long as there is some provision
> | that releases are not made at a too-high rate.
>
> I would agree, but...
> has there been
> > In effect, this is what the PEP says. That's intentional (i.e. it
> > is my intention - others may have different intentions). It's the
> > repository that holds the security patches; the tarballs (and the
> > version number bumps) are just a convenience.
>
> It's not the intentions of th
"Martin v. Löwis" writes:
> > In general, I recognize the burden on the release engineer, and
> > obviously any burdensome policy needs his OK. But I think the policy
> > should be *effective* too, and I just don't see that a policy that
> > allows such long lags is a more effective security
> Still, I'm in agreement with you that the repository holds the security
> patches and that the tarballs are a convenience. They are an important
> convenience though, so I would say that they should be released in a
> timely manner after the commit of the security patches. I don't think
> we ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 14, 2007, at 5:32 PM, Martin v. Löwis wrote:
>> We should decide what's right for security releases and then assess
>> whether we need to recruit in order to perform that activity the
>> way we
>> want to.
>
> I disagree. If you would like to
> We should decide what's right for security releases and then assess
> whether we need to recruit in order to perform that activity the way we
> want to.
I disagree. If you would like to see a certain policy implemented, you
need to locate the volunteers *first*, and only then you can start
setti
> My point is that if those steps are required for a release, the branch
> is not "immediately releasable" by my standards if they're not done.
> Especially if a release candidate is required.
But how does that help in practice? If you find after the release that
the branch was not in a releasable
Martin v. Löwis wrote:
>> I don't understand the point of a "security release" made up to a year
>> after commit, especially in view of the first quoted paragraph.
>
> The objective is to reduce load for the release manager. Any kind of
> release that is worth anything takes several hours to pro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 14, 2007, at 11:32 AM, Stephen J. Turnbull wrote:
> In general, I recognize the burden on the release engineer, and
> obviously any burdensome policy needs his OK. But I think the policy
> should be *effective* too, and I just don't see that a
"Martin v. Löwis" writes:
> The objective is to reduce load for the release manager. Any kind of
> release that is worth anything takes several hours to produce, in
> my experience (if it could be made completely automatic, it wouldn't
> be good, since glitches would not be detected).
I absol
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> I don't understand the point of a "security release" made up to a year
| > after commit, especially in view of the first quoted paragraph.
A security release is presumably a response to a serious problem.
| I thi
> I don't understand the point of a "security release" made up to a year
> after commit, especially in view of the first quoted paragraph.
The objective is to reduce load for the release manager. Any kind of
release that is worth anything takes several hours to produce, in
my experience (if it c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 12, 2007, at 9:02 AM, Stephen J. Turnbull wrote:
> I don't understand the point of a "security release" made up to a year
> after commit, especially in view of the first quoted paragraph. A
> commit may not be made without confirming *immediat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 12, 2007, at 4:29 AM, Martin v. Löwis wrote:
> This PEP attempts to formalize the existing practice, but goes beyond
> it in introducing security releases. The addition of security releases
> addresses various concerns I heard over the last yea
"Martin v. Löwis" writes:
> A security fix must not risk the releasability of the branch, i.e. the
> maintenance branch should be in a shape to produce a release out of it
> as-is at all times.
[...]
> Security releases should be made at most one year after a security
> patch has been commi
Martin v. Löwis wrote:
> Please let me know what you think.
This appears to be an accurate description of the way releases have been
handled for the last few years (which appears to be working well), so +1
here.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
This PEP attempts to formalize the existing practice, but goes beyond
it in introducing security releases. The addition of security releases
addresses various concerns I heard over the last year about Python
being short-lived. Those concerns are typically raised by Linux
distributors which see that
20 matches
Mail list logo
