Re: Patching guidelines

[Rik]

On 03/17/2012 02:38 PM, address@hidden wrote:
> Message: 7
> Date: Sat, 17 Mar 2012 15:46:34 -0400
> From: Jordi Guti?rrez Hermoso <address@hidden>
> To: Octave Maintainers List <address@hidden>
> Subject: Patching on stable?
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> While I'm trying to get the rules clear, I would also like some
> clarification on what is appropriate for the stable branch, because
> I'm never sure.
>
> The following is obviously appropriate:
>
>   * Regressions since past stable releases
>   * Critical bugs (but is a crash always crtical?)
>
> The following is less clear:
>
>   * Documentation fixes
>   * Minor bugs (accuracy, incorrect results)
>
> The follow is never good for the stable branch:
>
>    * Breaking ABI compatibility
>    * Adding new functionality
>    * Deprecating or removing functions.
>
> Could we have a clear document somewhere that addresses all these? I'm
> always trying to guess when is patching on stable acceptable or not.
> My current heuristic is, if I'm not certain it's a regression or a
> critical bug, I don't patch on stable without asking first. Is that
> how it should stay?
>
> - Jordi G. H.
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 17 Mar 2012 17:37:52 -0400
> From: Ben Abbott <address@hidden>
> To: Jordi Guti?rrez Hermoso <address@hidden>
> Cc: Octave Maintainers List <address@hidden>
> Subject: Re: Patching on stable?
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Mar 17, 2012, at 3:46 PM, Jordi Guti?rrez Hermoso wrote:
>
>> > While I'm trying to get the rules clear, I would also like some
>> > clarification on what is appropriate for the stable branch, because
>> > I'm never sure.
>> > 
>> > The following is obviously appropriate:
>> > 
>> >  * Regressions since past stable releases
>> >  * Critical bugs (but is a crash always crtical?)
I consider a crash to always be critical.  The program may warn, or even
throw an error, but it shouldn't crash when given an arbitrary input.
>> > 
>> > The following is less clear:
>> > 
>> >  * Documentation fixes
>> >  * Minor bugs (accuracy, incorrect results)
>> > 
>> > The follow is never good for the stable branch:
>> > 
>> >   * Breaking ABI compatibility
>> >   * Adding new functionality
>> >   * Deprecating or removing functions.
>> > 
>> > Could we have a clear document somewhere that addresses all these? I'm
>> > always trying to guess when is patching on stable acceptable or not.
>> > My current heuristic is, if I'm not certain it's a regression or a
>> > critical bug, I don't patch on stable without asking first. Is that
>> > how it should stay?
>> > 
>> > - Jordi G. H.
> Looks good to me. For the "less clear" I think we should avoid these as well.
>
> Of course, specific examples can be discussed on the list.
According to JWE, documentation fixes are always acceptable since they
won't break ABI, etc.  However, I also think documentation fixes aren't
that critical so there's no reason users can't get them in 6 months when
the next major release comes out.  This also makes the stable branch more
"stable" because it is less frequently patched even for trivial things like
misspellings.  Accordingly, these days I do documentation improvements on
the default branch.  An exception would be something where we documented
that you needed to use a certain version of a library, but in fact you need
a different one.  In that case I could see clarifying the situation on the
stable branch.

As for less critical bugs like accuracy, etc., I push those on the default
branch. 

--Rik