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.
B.
On Mon, Jan 3, 2011 at 3:49 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> On Jan 3, 2011, at 9:01 AM, Filipe David Manana wrote:
>
>> On Mon, Jan 3, 2011 at 1:47 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>> On Mon, Jan 3, 2011 at 1:50 PM, Robert Newson <robert.newson@gmail.com>
wrote:
>>>> 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
|