db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Code changes going forward
Date Fri, 24 Sep 2004 22:28:56 GMT
Hash: SHA1

Looking at the DB guidelines that the Derby project voted to follow
it seems that generally code changes are subject to lazy approval.
(see 'Product Changes' in http://db.apache.org/decisions.html)

Only changes that are 'Doubtful changes, new features, and large scale
overhauls' and 'Any change that affects the semantics of an existing API
function, the size of the program, configuration data formats, or other
major areas' need to have a consensus approval vote before commit.

So it seems a committer can commit any patch that they think is "low
risk" without waiting for a vote. I would say, as examples, that Myrna's
patch and my patch would fall into that category. I'm assuming that bug
fix patches are always good to apply, assuming they fix the bug correctly.

Myrna's -
Mine -

Obviously with some changes one committer may commit a patch they think
is ok, but someone else thinks it should be voted on. This is covered by
that person either raising the issue when the patch is first posted or
voting a veto when the patch is committed. Then the lazy approval turns
into a consenus vote.

Any committer who does apply a patch is required to e-mail to the list
and the originator of the patch, the fact that the patch was applied.

Does this seem reasonable to folks?

Just trying to make sure I understand our open source model.
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message