couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: svn commit: r1054594 - in /couchdb/trunk: etc/couchdb/ src/couchdb/
Date Mon, 03 Jan 2011 16:19:48 GMT
Completely agree. I don't want us to have to file a ticket for every
single commit either. The trouble is one persons "trivial" is not
everyone's. In my opinion, and it's merely that, tweaking
startup/supervisor stuff is non-trivial, even if expressed in a
handful of lines, as it can change how we all reason about how couchdb
processes handle failures.

Reasonable cases for committing without a ticket are correcting typos
in comments and adding new (passing) tests but I don't think it's
useful to provide an exhaustive list of such things.

Finally, if your commit introduces new modules then a ticket and a
patch should be preferred.


On Mon, Jan 3, 2011 at 3:49 PM, Adam Kocoloski <> wrote:
> On Jan 3, 2011, at 9:01 AM, Filipe David Manana wrote:
>> On Mon, Jan 3, 2011 at 1:47 PM, Benoit Chesneau <> wrote:
>>> On Mon, Jan 3, 2011 at 1:50 PM, Robert Newson <>
>>>> Seconded. That's a big change with zero discussion and no Jira ticket.
>>>> +1 on reverting until a discussion is had.
>>>> B.
>>> These changes don't introduce any regressions, and are well tested.
>>> Did you read the code ?
>> It's not a question of reading or not the code.
>> All the tests pass, but to me that only means "maybe there aren't any
>> regressions".
>> I believe there are very good reasons for having it in Bigcouch and CouchDB.
>> But I would like to have before a vote and have feedback from Adam
>> regarding no issues with standard CouchDB, as I believe he's the one
>> that knows better what the implications might be.
> In my opinion all of the changes in Benoit's commit belong in CouchDB, I simply haven't
gotten around to introducing them.  I do think that the right way to commit them is to separate
the patch into a series of independent, isolated changesets.
> I think that the practice of filing a JIRA ticket for each non-trivial commit (aka the
fdmanana method) is reasonable and not too onerous.  Detailed commit messages describing
the reason for the change (aka the davisp method) are also a good idea for the changes we're
discussing here, as they improve the interaction between CouchDB and the OTP subsystem in
subtle but important ways.
> I don't want us to move to a strict RTC procedure; the lazy consensus we've been using
so far has worked just fine in my opinion.  Best,
> Adam

View raw message