Information for Developers

Alioth accounts

You need to create an Alioth account in order to access ["DebianGis/Repository"] and SVN. If you are already a Debian Developer, you already have one with your usual username, else you can create a new one [https://alioth.debian.org/account/register.php here] which will look like user-guest. Alioth is a [http://www.gforge.org Gforge] based distributed development environment, which collects and gives uniform access to a complete set of commonly used tools for free software projects.

After registering, you can contact one of the Project Manager of the [https://alioth.debian.org/projects/pkg-grass/ Alioth Grass Project] to have your account added to the pkg-grass group and have useful information and hints to access the repository. When you adopt a (possibly new) package you should communicate your intention to the pkg-grass-general list and add information in ["DebianGis/PackageList"]. Due to historical reasons the DebianGis project uses the pkg-grass repository and tools on Alioth, but it is not limited to grass-related software.

The SVN repository is hosted on svn.debian.org whose accounts are kept in sync with Alioth ones on regular basis. So you will be able to access the repository by svn+ssh for checkouts and commits. If you are not familiar with SVN please read the [http://svnbook.red-bean.com/en/1.0/index.html SVN book]. Minimally, you can checkout the grass repository by using a command like:

 svn checkout svn+ssh://your_username@svn.debian.org/svn/pkg-grass/packages/pkg-grass/trunk

and many commands are CVS-like. Please remember to use svn export in order to create a clean environment for the package (without the .svn stuff) before the final building for uploading a package. If you had doubts about convention (branches and tags) used in the repository, please ask on a mailing list. Some packages are maintained by means of svn-buildpackage and svn-inject, some others not.

Package versioning

A good habit is adopting a package versioning which is compatible with usual Debian versioning. You should always ensure that the version number adopted allows a proper dist-upgrade path and does not break uploads either in the main archive or in the debian-gis one. If the upstream version of a package (e.g. 5.7.0) was not present in the Debian official archive, you should number DebianGis versions as 5.7.0-0.0.dgis.distribution.N where N=1,2,... and distributioN is the code name of stable, testing or unstable (at the time of writing, sarge, etch and sid). This ensures proper dist-upgrading from one DebianGis distribution to another and allows developers to upload a 5.7.0-1 version without problems for users. At the same time, users could make nicely upgrades from the DebianGis archive. If your packages was a fork of a package already present in Debian (e.g 5.7.0-10), the proper version would be 5.7.0-9.0.dgis.distribution.N instead. We strongly suggest to verify version order before any upload, by using dpkg --compare-versions. If in doubt, please ask on pkg-grass-general list.

Follow usual policy for upstream versions. Therefore, release RC versions only by either post-fixing strings to current ones (e.g 0.9+1.0RC1-1 to release a pre-1.0 candidate version of a package), or using the magic ~ character (not currently suggested until sarge release, anyway the previous example would become 1.0~RC1-1). Find more information about that in the current [http://www.debian.org/doc/debian-policy/ Debian Policy] manual. Again, please ask on the list when not sure.

Experimental staging areas

We recently introduced a couple of experimental staging areas, stable-experimental and unstable-experimental, which can be used for very experimental stuff to be used within an ordinary stable or unstable distribution, respectively, as the names say. Both those repos are off the ordinary upgrading path of apt, so that packages there will need to be explicitly installed by users, by specifing their versions. So, those repositories can be safely added to either stable or unstable archives on any system. You can also use ordinary 'stable' and 'unstable' tags in the package versions just to avoid name redundancy.

Uploading

When uploading new upstream versions onto the debian-gis archive remember to use a -sa flag for dpkg-buildpackage in order to force the inclusion of the original tarball in the .changes meta file. That is mandatory because debian version is not -0 or -1. Of course, that is needed only for the first upload of the new version; successive ones can be built as usual.

An example section for your ~/.dupload.conf file follows below:

 $cfg{'debian-gis'} = {
        fqdn => "alioth.debian.org",
        method => "scpb",
        login => "frankie",
        visibleuser => "frankie",
        visiblename  => "debian.org",
        fullname => "Francesco Paolo Lovergine",
        incoming => "/var/lib/gforge/chroot/home/groups/pkg-grass/incoming",
        mailto => "pkg-grass-devel\@lists.alioth.debian.org",
        dinstall_runs => 0,
 };

Change login and names into yours, of course.

Here is a similar example for ~/.dput.cf

  [DEFAULT]
  login = frankie

  [debian-gis]
  method = scp
  fqdn = alioth.debian.org
  incoming = /var/lib/gforge/chroot/home/groups/pkg-grass/incoming

Adding your package to the DebianGis Status monitor

It is a good idea to add your source package to the [http://pkg-grass.alioth.debian.org/debiangis-status.html daily report] about the status of DebianGis. To do that you need to checkout the [http://svn.debian.org/wsvn/pkg-grass/scripts/?rev=0&sc=0 scripts directory from project SVN repository] and modify the dgis-packages.inc file to add the source file name to the list of monitored packages. Please, respect the perl syntax doing that, else you could break things.

Maintainership

If you would share your work with the group or co-maintain a package, ask for SVN committment rights to the list. It is a good practice adding yourself among Uploaders in the debian/control file and setting the Maintainer: field to 'Debian GIS Project <pkg-grass-devel@lists.alioth.debian.org>'. Also, it is better if you submit a few patches for DebianGis packages bugs before asking for committment access, if you are not a Debian Developer. From time to time, when uploading a new version of a package, check the list of Uploaders and remove people who did not do any commits since one year ore more, on the basis of the changelog contents. Please, avoid to upload a new package just to modify the Uploaders list, but try to keep the list as up-to-date as possible. A grain of salt should be used in updating the Uploaders list in case of slowly evolving products.

If you are looking for tasks that need to be completed, you can consult ["DebianGis/ToDo"] for packages which need updating, or the [http://pkg-grass.alioth.debian.org/debiangis-status.html DebianGis status page] for not-yet-packaged stuff. It is a good idea to annotate the work-in-progress in the ["DebianGis/ToDo"] page to avoid duplicate efforts.

Any doubt?

Just in case, ask on the [http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-general pkg-grass-general] list or query on the IRC #debian-gis channel on the OFTC network. It is also a good idea to subscribe the [http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel pkg-grass-devel] list to see commit logs, bug reports and other developers-only information and discussions.


CategoryTeams CategoryTeams