couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Commits to 1.1.x not in 1.0.x
Date Wed, 15 Jun 2011 15:52:31 GMT

On 15 Jun 2011, at 17:47, Sam Bisbee wrote:

> On Wed, Jun 15, 2011 at 11:17 AM, Paul Davis
> <paul.joseph.davis@gmail.com> wrote:
>> On Wed, Jun 15, 2011 at 10:49 AM, Sam Bisbee <sam@sbisbee.com> wrote:
>>> On Wed, Jun 15, 2011 at 9:43 AM, Paul Davis <paul.joseph.davis@gmail.com>
wrote:
>>>> I'm not at all sure that I need to. My reasoning for consideration was
>>>> as such: I looked at it, it wasn't in 1.0.x. The diff looked like it
>>>> would've been pretty close to applying without a merge. The behavior
>>>> change sounded appropriate but its using new mochiweb API's AFIACT.
>>>> 
>>>> As far as I can tell its not a major issue. And its and old bug that
>>>> no one has really reported so far as I can tell. If other people are
>>>> ok ignoring it I'd be tickled pink to ignore it as well.
>>> 
>>> Not suggesting that we necessarily need a long piece of paper, but is
>>> there any "policy" on what gets back ported? Would it make sense
>>> adding a line to the release procedure?
>>> 
>>> I could see a one liner in the house keeping section where we identify
>>> anything that was released as needing to be back ported. Or maybe
>>> that's just a step in the JIRA house keeping process.
>>> 
>>> Or maybe I just need more coffee.
>>> 
>>> Cheers,
>>> 
>>> --
>>> Sam Bisbee
>>> www.sbisbee.com
>>> 
>> 
>> In theory it's simply "bug fixes get backported". But then we realize
>> the whole "in practice" part of the quote.
> 
> There's an "in practice" part of the quote? :)
> 
> Also, do we really need to back port all bug fixes? I would assume
> that we'd only need to back port fixes for issues that were introduced
> earlier (ie., don't back port fixes to 1.1.x for issues introduced in
> 1.0.x).
> 
> Maybe to make it less of a burden we set a limit on the issues'
> severity. Such as, we'll only support back porting issues of a
> critical severity (randomly chosen). If people want a lower severity
> fix, then they can back port it themselves - patches welcome!

I think the way we are doing this today is fine, developers check in
fixes into trunk and backport if they see fit. Finally, the release
master does a double check and gets consensus on missing items.

Cheers
Jan
-- 


Mime
View raw message