Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys



lacombar%gmail.com@localhost wrote:

> On Wed, Jun 24, 2009 at 6:42 AM, Izumi 
> Tsutsui<tsutsui%ceres.dti.ne.jp@localhost> wrote:
> > - it's reasonable for me that we should wait at least a week
> >  before to consider "no response means no objections."
> >
> FWIW, I'm not sure the policy "wait for objection and commit if none"
> is the best to follow. I (personally) prefers the "wait for approval
> and commit" one.

We already have some guidelines:

http://www.NetBSD.org/developers/commit-guidelines.html
>> 4. The more intrusive your changes are the higher is the level of
>>    required prior approval.
>> 
>>  * "Obvious" fixes can be committed without any prior discussion
>>    or review. (The definition of "obvious" in the GCC Project is:
>>    "could not possibly cause anyone to object." We adopt this
>>     definition here)
>>  * All other (i. e. "non-obvious") fixes should have a review.
>>  * Implementing (significant) new features requires a prior
>>    discussion on an appropriate technical mailing list.
>>  * Changing existing interfaces in libraries or in the kernel
>>    requires prior approval by Core.

But there is no explicit definition about responsible persons
who should respond each call for review in the middle two cases.

We are volunteered project[TM] so all reviews can't be done with
timely manner, unfortunately. In some case, it took more than a year
to get "looks good" comment. Is it still reasonable and the best for you? 

In my opinion, if one's changes can safely be reverted later
(i.e. adding a new driver, or no public API changes, etc.)
the policy "approved by no objection" may be acceptable, and
one week seems reasonable compromise for me in that case
because too long priod could spoil developer's motivations.

(approvals in private discussion without authorized persons
 in the area could be more problematic..)
---
Izumi Tsutsui


Home | Main Index | Thread Index | Old Index