[postgis-devel] Java Maintenance

Baris Ergun barisergun75 at gmail.com
Thu Feb 27 11:37:07 PST 2014 

RFC-5: PostGIS Committer
Guidelines<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#RFC-5:PostGISCommitterGuidelines>
Version: 1.00000013Author: Regina Obe <lr at pcorp dot us>Last Edited:
2012/05/04 Status:Approved Changes to this
file<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#Changestothisfile>

This RFC should be only changed by PostGIS PSC members. All PSC members
must agree to the terms of the changes before the change is considered
final except in the case of wording changes and formatting that do not
alter the terms of the guidelines.
Purpose <https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#Purpose>

To formalize source tree access, and specify some guidelines for source
committers and patch submitters.
Election to Commit
Access<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#ElectiontoCommitAccess>

Permission for commit source tree access shall be provided to new
developers only if accepted by the PostGIS Project Steering Committee. A
proposal should be written to the PSC for new committers and voted on
normally. It is not necessary to write an RFC document for these votes, a
proposal to postgis-dev is sufficient.

Removal of commit access should be handled by the same process.

The new committer should have demonstrated commitment to PostGIS and
knowledge of the PostGIS source code and processes to the committee's
satisfaction, usually by reporting bugs, submitting patches, and/or
actively participating in the PostGIS mailing list(s).

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.

All committers should also be a member of the postgis-dev mailing list so
they can stay informed on policies, technical developments and release
preparation.

New committers are responsible for having read, and understood this
document.
Code and Documentation
Conventions<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#CodeandDocumentationConventions>

   - C code should follow our designated Style
Guidelines<http://trac.osgeo.org/postgis/browser/trunk/STYLE> to
   the best of your abilities. -> BE We can add
   http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.htmlfor
Java
   - All source code in SVN should be in Unix text format as opposed to DOS
   text mode. (Ok I use nix based hosts @home @office)
   - Each new/changed function should be documented in the official docs
   following our Documentation
Guidelines<https://trac.osgeo.org/postgis/wiki/DevWikiDocNewFeature>
    OK

SVN Administrator<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#SVNAdministrator>

One member of the Project Steering Committee will be designated the SVN
Administrator. That person will be responsible for giving SVN commit access
to folks, updating the CREDITS and authors.svn file, and other SVN related
management. That person will need login access on the SVN server of course.

Initially Paul Ramsey will be the SVN Administrator.
SVN Commit and Bug, Feature Tracking
Practices<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#SVNCommitandBugFeatureTrackingPractices>

The following are considered good source commit and tracking practices for
the PostGIS project.

   1. Use meaningful descriptions for commit log entries. OK
   2. Add a bug reference like
"#1232<https://trac.osgeo.org/postgis/ticket/1232>"
   at the beginning or end of SVN commit log entries when committing changes
   related to a ticket in Trac. The '#' character enables Trac to create a
   hyperlink from the changeset to the mentioned ticket.  OK I hope there
   is an svn server script which is preventing me in case of human errors Ie
   it can check if Trac Issue is open and #1232 number format is correct.
   3. When new enhancements are added or breaking changes are made and
   completed the related ticket should have in *keywords* section of ticket
   the word *history*. This will better ensure it is not forgotten when
   preparing the news release and official doc release notes.OK
   4. After committing changes related to a ticket in Trac, write the tree
   and revision in which it was fixed in the ticket description. Such as
   "Fixed in trunk r12345 and in branches/1.7 r12346". The 'r' character
   enables Trac to create a hyperlink from the ticket to the changeset.OK
   but I dont understand how the changeset is collected from the revision
   number. Isnt the revision number a specifier of the atomic commit in SVN?
   SO specifiying the revision number as a comment in Trac may help us create
   hyperlink from only that latest commit changeset and not all the other
   previous commit changesets related to that issue?
   5. Changes should not be committed in stable branches without a
   corresponding bug id. Any change worth pushing into the stable version is
   worth a bug entry. OK I think this was mentioned in 2
   6. Never commit new features to a stable branch without permission of
   the PSC or release manager. Normally only fixes should go into stable
   branches. OK make sense
   7. New features go in the main development trunk. OK
   8. Only bug fixes should be committed to the code during pre-release
   code freeze, without permission from the PSC or release manager. OK
   9. Significant changes to the main development version should be
   discussed on the postgis-dev list before you make them, and larger changes
   will require an RFC approved by the PSC.OK
   10. Do not create new branches (except for spike branches) without the
   approval of the PSC. Release managers are assumed to have permission to
   create a branch. OK
   11. spike branch (those in the spike/username area are to be used for
   experimentation or for major code refactoring that will destabilize the
   trunk. After such experimentation is deemed stable, this can then be merged
   into the trunk after approval from PSC members. OK
   12. When committing new features or significant changes to existing
   source code, the committer should take reasonable measures to insure that
   the source code continues to build and work on the most commonly supported
   platforms (currently Linux and Windows), either by testing on those
   platforms directly, running Buildbot tests, or by getting help from other
   developers working on those platforms. If new files or library dependencies
   are added, then the configure.in, Makefile.in and related documentations
   should be kept up to date. NA
   13. In the event of broken build (build bot fail notification), the
   person who broke the build must fix the break before working on anything
   else OK

Committer Tracking<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#CommitterTracking>

A list of all project committers will be kept in the main postgis directory
in a file called (CREDITS) listing for each SVN committer. This will be the
responsibility of the PSC to ensure:

   - Userid: the id that will appear in the SVN logs for this person.
   - Full name: the users actual name.
   - Email address: A current email address at which the committer can be
   reached. It may be altered in normal ways to make it harder to auto-harvest.
   - A brief indication of areas of responsibility.
   - The name of key developers and their area of responsibility should
   also be prominently shown in latest release of manual in the
   doc/introduction.xml file. This will be the responsibility of the
   documentation lead to ensure.

Relationship with other
Projects<https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#RelationshipwithotherProjects>

Some parts of the PostGIS code base are dependent on other upsteam projects
or other projects rely heavily on functionality in PostGIS. Changes in
those areas should go first into those upstream projects and then applied
to PostGIS. In event of major changes to PostGIS, said projects should be
regression tested (before a PostGIS release) to ensure the latest version
still works with the latest RTM version of PostGIS.

Currently the list of those areas is :

   - postgresql (  http://www.postgresql.org <http://www.postgresql.org/>)
   - geos (  http://geos.osgeo.org <http://geos.osgeo.org/>)
   - proj (  http://proj.osgeo.org <http://proj.osgeo.org/>)
   - gdal (  http://gdal.osgeo.org <http://gdal.osgeo.org/>)

GIS FOSS suites that need testing before PostGIS major release:

   - mapserver ( http://mapserver.org <http://mapserver.org/>)
   - geoserver ( http://geoserver.org <http://geoserver.org/>)
   - openjump ( http://openjump.org <http://openjump.org/>)
   - qgis ( http://qgis.org <http://qgis.org/>)
   - gvSig ( http://www.gvsig.org <http://www.gvsig.org/>)
   - pgRouting ( http://www.pgrouting.org/ <http://www.pgrouting.org/>)
   - osm2pgsql + other openstreetmap components (mapnik etc) (
   http://www.openstreetmap.org/ <http://www.openstreetmap.org/>)

Legal <https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines#Legal>

Committers are the front line gatekeepers to keep the code base clear of
improperly contributed code. It is important to the PostGIS users,
developers and the OSGeo foundation to avoid contributing any code to the
project without it being clearly licensed under the project license.

Generally speaking the key issues are that those providing code to be
included in the repository understand that the code will be released under
the original GPL license, and that the person providing the code has the
right to contribute the code. For the committer themselves understanding
about the license is hopefully clear. For other contributors, the committer
should verify the understanding unless the committer is very comfortable
that the contributor understands the license (for instance frequent
contributors).

If the contribution was developed on behalf of an employer (on work time,
as part of a work project, etc) then it is important that an appropriate
representative of the employer understand that the code will be contributed
under the GPL license. The arrangement should be cleared with an authorized
supervisor/manager, etc.

The code should be developed by the contributor, or the code should be from
a source which can be rightfully contributed such as from the public
domain, or from an open source project under a compatible license.

All unusual situations need to be discussed and/or documented.

Committers should adhere to the following guidelines, and may be personally
legally liable for improperly contributing code to the source repository:

   - Make sure the contributor (and possibly employer) is aware of the
   contribution terms.
   - Code coming from a source other than the contributor (such as adapted
   from another project) should be clearly marked as to the original source,
   copyright holders, license terms and so forth. This information can be in
   the file headers, but should also be added to the project licensing file if
   not exactly matching normal project licensing.
   - Existing copyright headers and license text should never be stripped
   from a file. If a copyright holder wishes to give up copyright they must do
   so in writing to the foundation before copyright messages are removed. If
   license terms are changed it has to be by agreement (written in email is
   ok) of the copyright holders.
   - Code with licenses requiring credit, or disclosure to users should be
   added to /postgis/trunk/LICENSE.TXT.
   - When substantial contributions are added to a file (such as
   substantial patches) the author/contributor should be added to the list of
   copyright holders for the file.
   - If there is uncertainty about whether a change is proper to contribute
   to the code base, please seek more information from the project steering
   committee, or the foundation legal counsel.
   - New contributors and company contributors should be added to the
   credits in doc/introduction.xml of the latest release of the PostGIS manual.
   - It is the responsibility of the document lead to insure when new
   enhancements are added or breaking changes are made, these are noted in the
   trunk/NEWS or relevant branch/NEWS as soon as conveniently possible. The
   note should include the trac # (unless a major feature with many tickets)
   and contributors to the feature/change.
   - OK



On 26 February 2014 13:50, Baris Ergun <barisergun75 at gmail.com> wrote:

> Iwill reply soon generraly it looks like I will comply all the rules.
> Just will read the doc carefully and also add some suggestions for Java
> Code Style reference etc.
>
>
> On 25 February 2014 23:04, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>
>> Aye, Baris, do you agree to conform to the committer guidelines (in
>> particular note items 5,6,7 on stable branches and appropriate changes)
>>
>> https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines
>>
>> And as an added note, to stick to committing in the Java area.
>>
>> P.
>>
>>
>> --
>> Paul Ramsey
>> http://cleverelephant.ca
>> http://postgis.net
>>
>> On February 25, 2014 at 1:02:16 PM, Sandro Santilli (strk at keybit.net<//strk at keybit.net>)
>> wrote:
>>
>> On Tue, Feb 25, 2014 at 12:25:29PM -0800, Paul Ramsey wrote:
>> > Hi Devs,
>> > We have the potential for active maintenance of the Java chunk of the
>> distribution, and I would like to give Baris Ergun commit privs to the java
>> sub-tree. He’s already provided a couple of patches that look fine, and
>> most importantly is thinking about the implications of his changes in the
>> large before applying.
>> > Please give me a vote on that (the alternative is continuing Java
>> branch bitrot)
>>
>> +1 for a java side maintainer
>>
>> Please don't forget to test his resilience of burocratic pressure:
>> https://trac.osgeo.org/postgis/wiki/DevWikiComitGuidelines
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>>
>>
>
>
> --
> Barış
> www.linkedin.com/in/barisergun
>



-- 
Barış
www.linkedin.com/in/barisergun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140227/6f465a59/attachment.html>

More information about the postgis-devel mailing list