couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Bisbee <>
Subject Re: Commits to 1.1.x not in 1.0.x
Date Wed, 15 Jun 2011 15:47:25 GMT
On Wed, Jun 15, 2011 at 11:17 AM, Paul Davis
<> wrote:
> On Wed, Jun 15, 2011 at 10:49 AM, Sam Bisbee <> wrote:
>> On Wed, Jun 15, 2011 at 9:43 AM, Paul Davis <> 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
> 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

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!

Sam Bisbee

View raw message