[postgis-devel] Commit gudelines agreement

Paragon Corporation lr at pcorp.us
Mon May 16 09:50:34 PDT 2011


Mark,

> I don't think that was the intention based upon the way it was worded. I
must admit when I read Olivier's comment I was a little bit shocked until I
read the paragraph in its entireity:

> "The new committer should also be prepared to support any new feature or
changes that he/she commits to the PostGIS 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."

> I can see that this is to stop cases where a company may sponsor a new
piece of code, get it committed, and then disappear leaving everyone else to
support it. Perhaps re-word it > to "any *major* new feature or changes"?

I would just assume leave it out otherwise we may end up getting into petty
arguments about what is a major feature or not.  3D stuff is major to me and
not necessarily major to others for example.  
I think if something is major enough to peoples work processes, someone is
going to step up to the plate to manage it, and if no one does, chances are
it wasn't that major anyway.


> I also noticed this:

> "If new files or library dependencies are added, then the configure.in,
Makefile.in and related documentations should be kept up to date."

> I would much rather have it that any dependency changes should be
discussed on the development list beforehand as I can see that this can
cause issues for some platforms, e.g. > Windows where not all libraries may
be available.

I'm usually the first one that gets screwed when someone makes these
changes.  Unfortunately I don't know I am screwed until I am screwed.  
With that said, I don't think there is much point in having such a
discussion.  If I can't compile anymore, you'll hear about it and you'll
hear a bunch of other people screaming in the background as well.  I think
the "If you break the build.... " you must fix it before doing anything
else, wards off most  of these issues sufficiently.

Thanks,
Regina





More information about the postgis-devel mailing list