You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2015/02/03 17:06:17 UTC
Support Policies for Corinthia releases
I was just pointed to this interesting post about depth of support for released artifacts:
<http://www.tedunangst.com/flak/post/long-term-support-considered-harmful>.
That article links to an interesting problem about the GHOST exploit against a vulnerability in glibc,
<https://blog.hboeck.de/archives/864-What-the-GHOST-tells-us-about-free-software-vulnerability-management.html>.
It strikes me that it is important that any support policy be explicit. That is, when does/will support for a version end, what exceptions might there be, and for how long.
It is also important to have an effective way for downstream users to know when the support life is/will end for a given release or related binaries, and to be able to know when a new release provides critical updates that may impact their usage. Some creativity may be needed for accomplishing effective notifications.
- Dennis
THINKING OUT LOUD
There can be two factors in this. Releases that repair serious defects, such as crashers, data corruption, and security vulnerabilities my involve fixes to Corinthia source codes. They may involve dependencies in convenience binaries where the defect in the dependency extends into Corinthia.
Even though the replacement of a dependency version may be a minor change in the Corinthia code base, it may be appropriate to do a release and make new convenience binaries for built libraries and executables that the dependency is bolted into that code. This support-life business should perhaps be a factor in deciding exactly what convenience binaries the project is willing to provide and support.
I think we need to be clear about what level of release versions counts with respect to the aging policy. Going from m.n.p to m.n.(p+1) probably should not (assuming a "semantic versioning" practice). Going from m.n.* to m.(n+1).* probably should count as a version step in terms of any support assurance. If the policy is to extend support two back, it would be at that m.* level. When there is a change at the m level, One might support the previous two releases for a longer time because of the m+1 changes being so significant, especially if there is a change in system requirements.
-- Dennis E. Hamilton
orcmid@apache.org
dennis.hamilton@acm.org +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
Re: Support Policies for Corinthia releases
Posted by Dave Fisher <da...@comcast.net>.
I like the idea. Let us see what organically grows around the code base.
Not every column in our temple complex will be corinthian.
On Feb 3, 2015, at 9:12 AM, Dennis E. Hamilton wrote:
> +1 on no convenience binaries until there is stability and capacity for support.
> I do think one needs to keep this in mind in terms of organization for
> builds and how releases are identified (and dependencies handled), but
> only that.
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Tuesday, February 3, 2015 08:21
> To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
> Subject: Re: Support Policies for Corinthia releases
>
> On Tuesday, February 3, 2015, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
> [ ... ]
>> It strikes me that it is important that any support policy be explicit.
>> That is, when does/will support for a version end, what exceptions might
>> there be, and for how long.
>>
>> It is also important to have an effective way for downstream users to know
>> when the support life is/will end for a given release or related binaries,
>> and to be able to know when a new release provides critical updates that
>> may impact their usage. Some creativity may be needed for accomplishing
>> effective notifications.
>
> Well for this project we might choose only to release source and avoid all
> these problems, at least for a long time until DocFormat is stable.
>
> Some of us might outside the project provide convenience binaries.
>
> So in total I do not really see downstream users or binary releases before
> DocFormat is stabilized. At the moment we do not have resources to support
> that.
>
> [ ... ]
>
RE: Support Policies for Corinthia releases
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 on no convenience binaries until there is stability and capacity for support.
I do think one needs to keep this in mind in terms of organization for
builds and how releases are identified (and dependencies handled), but
only that.
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Tuesday, February 3, 2015 08:21
To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: Support Policies for Corinthia releases
On Tuesday, February 3, 2015, Dennis E. Hamilton <de...@acm.org>
wrote:
[ ... ]
> It strikes me that it is important that any support policy be explicit.
> That is, when does/will support for a version end, what exceptions might
> there be, and for how long.
>
> It is also important to have an effective way for downstream users to know
> when the support life is/will end for a given release or related binaries,
> and to be able to know when a new release provides critical updates that
> may impact their usage. Some creativity may be needed for accomplishing
> effective notifications.
Well for this project we might choose only to release source and avoid all
these problems, at least for a long time until DocFormat is stable.
Some of us might outside the project provide convenience binaries.
So in total I do not really see downstream users or binary releases before
DocFormat is stabilized. At the moment we do not have resources to support
that.
[ ... ]
Re: Support Policies for Corinthia releases
Posted by jan i <ja...@apache.org>.
On Tuesday, February 3, 2015, Dennis E. Hamilton <de...@acm.org>
wrote:
> I was just pointed to this interesting post about depth of support for
> released artifacts:
> <http://www.tedunangst.com/flak/post/long-term-support-considered-harmful
> >.
>
> That article links to an interesting problem about the GHOST exploit
> against a vulnerability in glibc,
> <
> https://blog.hboeck.de/archives/864-What-the-GHOST-tells-us-about-free-software-vulnerability-management.html
> >.
>
> It strikes me that it is important that any support policy be explicit.
> That is, when does/will support for a version end, what exceptions might
> there be, and for how long.
>
> It is also important to have an effective way for downstream users to know
> when the support life is/will end for a given release or related binaries,
> and to be able to know when a new release provides critical updates that
> may impact their usage. Some creativity may be needed for accomplishing
> effective notifications.
Well for this project we might choose only to release source and avoid all
these problems, at least for a long time until DocFormat is stable.
Some of us might outside the project provide convenience binaries.
So in total I do not really see downstream users or binary releases before
DocFormat is stabilized. At the moment we do not have resources to support
that.
just my opinion.
rgds
jan i
>
> - Dennis
>
> THINKING OUT LOUD
>
> There can be two factors in this. Releases that repair serious defects,
> such as crashers, data corruption, and security vulnerabilities my involve
> fixes to Corinthia source codes. They may involve dependencies in
> convenience binaries where the defect in the dependency extends into
> Corinthia.
>
> Even though the replacement of a dependency version may be a minor change
> in the Corinthia code base, it may be appropriate to do a release and make
> new convenience binaries for built libraries and executables that the
> dependency is bolted into that code. This support-life business should
> perhaps be a factor in deciding exactly what convenience binaries the
> project is willing to provide and support.
>
> I think we need to be clear about what level of release versions counts
> with respect to the aging policy. Going from m.n.p to m.n.(p+1) probably
> should not (assuming a "semantic versioning" practice). Going from m.n.*
> to m.(n+1).* probably should count as a version step in terms of any
> support assurance. If the policy is to extend support two back, it would
> be at that m.* level. When there is a change at the m level, One might
> support the previous two releases for a longer time because of the m+1
> changes being so significant, especially if there is a change in system
> requirements.
>
>
>
> -- Dennis E. Hamilton
> orcmid@apache.org <javascript:;>
> dennis.hamilton@acm.org <javascript:;> +1-206-779-9430
> https://keybase.io/orcmid PGP F96E 89FF D456 628A
> X.509 certs used and requested for signed e-mail
>
>
>
--
Sent from My iPad, sorry for any misspellings.