Commiter Responsibilities Guidelines

[robe]

​http://wiki.osgeo.org/wiki/Commiter_Responsibilities_Guidelines

I'll try to take a first stab at writing this and have Paul, Mark, Kevin, and dev team agree on if its acceptable or not.

[jorgearevalo]

I've modified the link to GDAL commiters guidelines. The right one is ​http://trac.osgeo.org/gdal/wiki/rfc3_commiters

[robe]

I have drafted one patterned after GDAL one. I'm not sure the numbering scheme we have for RFC's so wasn't sure what to put there.

I would like for all PSC members to take a look make any changes needed and for PostGIS developers (those with commit access to agree to the terms).

http://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines

[strk]

I've just fixed a typo. Shoud I have updated the version number in doing so ?

[strk]

The HISTORY note in commit log is new to me. I'd drop it, unless it's just me being unaware.

It seems like something meant for automatic NEWS file generation, which we're doing manually (at least, I am)

[robe]

Hmm maybe we should take your comit rights away

Well I would like to leave it in there. The reason is that its a pain to crawl thru the tickets and descriptions and figure out if something is notable or not.

I suppose we can take it out since I guess people would have a hard time remembering it, but it does pave the way for automation and not all tickets are history worthy so I can't just go by that.

[robe]

sure. So we'll call it version 1.000001 and move up from there

[robe]

Strk,

How about instead of putting HISTORY in svn, we revise the line to

If you do anything or accept a patch that should appear in release notes, please put a line in the release notes and in the docs\release_notes.xml stating it and the # trac number.

I think that would serve the same purpose perhaps better. I know you are good at doing that, but others are not (I admit I never remember until much after the fact) and its a bit of a pain just before release to scrounge around looking for what is note worthy.

[strk]

To be honest, I haven't updated the release_notes.xml file, just the NEWS file (assuming the former can be derived by the latter)

I'm not against the HISTORY trick on itself, just doesnt' sound like something developers are doing right now. I tried a git log —grep=HISTORY and found only 5 hits (3 of yours, 2 of Mark), last of which from March 2009…

If tagging really helps automation I'm all for it, but it sounds like something easy to forget, in which case you end up needing to commit something void just for the sake of enterying the NEWS item, which wouldn't be much different than committing a change in the NEWS file directly

NEWS editing seems more common:

git log NEWS | grep ^Author | sort -u
Author: mleslie <mleslie@b70326c6-7e19-0410-871a-916f4a2858ee>
Author: mschaber <mschaber@b70326c6-7e19-0410-871a-916f4a2858ee>
Author: nicklas <nicklas@b70326c6-7e19-0410-871a-916f4a2858ee>
Author: pramsey <pramsey@b70326c6-7e19-0410-871a-916f4a2858ee>
Author: robe <robe@b70326c6-7e19-0410-871a-916f4a2858ee>
Author: strk <strk@b70326c6-7e19-0410-871a-916f4a2858ee>

[robe]

Actually I'm fine with doing the release_notes.xml stuff and even the release notes, and I hear you about the history, I forget and then the way svn is converted it doesn't support the hook to go back and edit. Plus Pierre is afraid of touching xml files anyway for fear of getting cooties or something.

So lets just leave as added to the NEWS file and then I can transcribe later. Doing it after the fact is just too prone to error (and we miss a lot of stuff and back edit to past versions). I was also thinking maybe in trac adding keyword HISTORY. Then we can just do a query at the end from trac to pick up anything we missed.

[strk]

+1 for the trac HISTORY keyword

[robe]

I'm going to close this out since I think we have all agreed to the committer guidelines and modified the guidelines to our liking.