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 <[email protected]> wrote: > On Jan 3, 2011, at 9:01 AM, Filipe David Manana wrote: > >> On Mon, Jan 3, 2011 at 1:47 PM, Benoit Chesneau <[email protected]> wrote: >>> On Mon, Jan 3, 2011 at 1:50 PM, Robert Newson <[email protected]> >>> 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
