MS RFC 7: MapServer CVS Commit Management

[Steve Lime]

I've been using the (bug xxxx) notation too and would like to see that change. Other than that I've no problems with any of this, makes good sound sense. I wish there was a way to hold folks feet to the fire if they abandon their modifications but I don't know how that could be done (e.g. imagemaps, graticule). I guess folks coming in and out of the project is just a fact of life. 

I'd vote +1 (assuming the vote is open). 

Steve

>>> Daniel Morissette <dmorissette at DMSOLUTIONS.CA> 09/22/05 2:30 PM >>>
Thanks for taking the initiative on this Frank.

Frank Warmerdam wrote:
> 
> I am not in favor of requiring bug numbers in the main dev branch.
> If I come upon something that needs to be fixed up a bit (perhaps just
> a spelling mistake in an error message) I don't want to have to file a
> bug about it.  Generally I don't want to make the barrier-to-contribution
> to high, at least in the dev branch.
> 

I agree.

> Actually, we might want to apply the same rules about bug #'s in
> the dev branch between release code freeze and the creation of the
> branch.  A high threshold for change is appropriate then as well.
> 

Yes, please.

> Come to think of it, I think another requirement of being a committer should
> be that the person has to stay subscribed to mapserver-dev.
> 

Agreed as well.

A few more notes about the proposal:

In the "Election to CVS Commit Access", I would like to see something 
along the following lines:

"The new committer should have demonstrated commitment to MapServer and 
knowledge of the MapServer source code and processes to the committee's 
satisfaction, usually by reporting bugs, submitting patches, and/or 
actively participating in the various MapServer forums.

The new committer should also be prepared to support any new feature or 
changes that he/she commits to the MapServer source tree in future 
releases, or to find someone to which to delegate responsibility for 
them if he/she stops being available to support the portions of code 
that he/she is responsible for.

In the event that portions of code become orphan and none of the other 
committers wants to take ownership of them, then they may be removed 
from the source tree in future releases."

Under CVS Commit practices, you wrote:

> * Prefix CVS commit log entries with "Bug 1232: " when committing fixes for bugs in Bugzilla.
> 
> * Include an entry in the HISTORY file for any non-trivial changes committed in the main MapServer source tree. Make sure it is placed under the correct version heading and include bug numbers in these messages too.


I have been using "(bug 1232)" at the end of the change comment before 
(instead of the "Bug 1232:" prefix). I guess either way works, it's just 
a matter of picking one and sticking to it, but I think Sean Gillies 
wrote before that the "Bug 1232:" prefix breaks ReStructured Text 
formatting so the "(bug 1232)" suffix would be preferable.

Other items for the CVS Commit practices:

* The rule for the HISTORY.TXT in the development trunk is a bit more 
flexible: we include mention of every important change or bug fix in 
HISTORY.TXT, but minor fixes are not always listed in the dev trunk, 
otherwise the list would just become too long and useless.

* Never commit new features to a stable branch: only critical fixes. New 
features can only go in the main development trunk.

* Significant changes to the main development version should be 
discussed on the -dev list before you make them, and larger changes will 
require a RFC approved by the TSC.

I think that's it.

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca 
  DM Solutions Group              http://www.dmsolutions.ca/ 
------------------------------------------------------------