Thanks for the feedback Piotr. I've made all the changes you suggest, except one. I'll discuss that below and include an updated diff against master.
On Oct 19, 2015, at 11:26 PM, Piotr Ożarowski wrote: >I'm against this change. If we want all team packages to follow some >rules, these rules need to be in policy document, not on the wiki page. >I don't want this page to be removed, policy can even point to it, but I >want it to be crystal clear that the binding document is the policy, not >any other document in the internet (even if it's very helpful). > >What am I missing here is a set of branch/tag names and procedures >(f.e. I didn't know that git pull is not enough and I should gbp pull or >update pristine-tar branch by hand) and debian/patches related set of rules >(do we require git-dpm or can one use plain quilt of some other rules >are followed?) Here's my concern: I don't want too much duplication of information in multiple locations. That's a sure recipe for bitrot, and I know no one wants to have to edit information in more than one place. Until now, the wiki has been the more convenient place to make these changes, but I agree in principle with your opinion that some of that information must be captured in policy. So here's what I suggest. For standards we must all adhere to, such as branch and tag names, source-full branches, the use of git-dpm, and maybe a few other points, these should go in policy.rst. The wiki page points to the policy document but doesn't otherwise describe those details. That way, there's only one place to change when/if these standards change. The wiki then goes on to describe common workflows, how to create new repositories, mr, etc. These aren't specifically policy related but are mostly there to help developers get started, or handle tricky situations. If you're in agreement with that split, I'll update both the policy and wiki. Cheers, -Barry diff --git a/policy.rst b/policy.rst index c09f03a..aed57c0 100644 --- a/policy.rst +++ b/policy.rst @@ -1,19 +1,19 @@ -======================================== - Python Modules Packaging Team - Policy -======================================== +===================================== + Debian Python Modules Team - Policy +===================================== -:Author: Gustavo Franco <stra...@debian.org>, Raphaël Hertzog <hert...@debian.org> +:Author: Gustavo Franco <stra...@debian.org>, Raphaël Hertzog <hert...@debian.org>, Barry Warsaw <ba...@debian.org> :License: GNU GPL v2 or later :Introduction: - Python Modules Packaging Team aims to improve the python modules situation - in Debian, by packaging available modules that may be useful and providing - a central location for packages maintained by a team, hence improving - responsiveness, integration and standardization. - - PMPT or just python-modules is hosted at alioth.debian.org, the Debian - GForge installation. We currently have a SVN repository and a mailing list - whose email address can be used in the Maintainer field on co-maintained + The Debian Python Modules Team (DPMT) aims to improve the Python modules + situation in Debian, by packaging available modules that may be useful and + providing a central location for packages maintained by a team, hence + improving responsiveness, integration, and standardization. + + The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We + currently have a git repository and a mailing list whose email address can + be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained packages. For more information send a message to: debian-python@lists.debian.org @@ -24,16 +24,21 @@ Joining the team ---------------- -The team is open to any python-related package maintainer. To be added on -the team, please send your request on debian-python@lists.debian.org -indicate why you want to join the team: maintain your current packages -within the team, help maintain some specific packages, etc. -Don't forget to indicate your Alioth login ! +The team is open to any Python-related package maintainer. To be added to +the team, please send your request to debian-python@lists.debian.org. Include +the following in your request: -Any Debian developer who wishes to integrate his packages in the team can do so -without requesting access (as the repository is writable by all DD). If one +* Why you want to join the team: e.g. maintain your current packages within + the team, help maintain some specific packages, etc. +* Your Alioth login. +* A statement that you have read + https://python-modules.alioth.debian.org/policy.html and that you accept it. + +Any Debian developer who wishes to integrate his packages in the team can do +so without requesting access (as the repository is writable by all DD). If one wants to be more involved in the team, we still recommend requesting_ access -so that he appears in the public member list displayed on Alioth's project page. +so that they appear in the public member list displayed on Alioth's project +page. The team accepts all contributors and is not restricted to Debian developers. Several Debian developers of the team will gladly sponsor packages of non-DD @@ -48,71 +53,35 @@ Maintainership -------------- A package maintained within the team should have the name of the team either -in the Maintainer field or in the Uploaders field. +in the ``Maintainer`` field or in the ``Uploaders`` field. Maintainer: Debian Python Modules Team <python-modules-t...@lists.alioth.debian.org> This enables the team to have an overview of its packages on the DDPO_website_. -* Team in Maintainers is a strong statement that fully collaborative - maintenance is preferred. Anyone can commit to the vcs and upload as - needed. A courtesy email to Uploaders can be nice but not required. +* Team in ``Maintainers`` is a strong statement that fully collaborative + maintenance is preferred. Anyone can commit to the git repository and upload + as needed. A courtesy email to ``Uploaders`` can be nice but not required. -* Team in Uploaders is a weak statement of collaboration. Help in maintaining - the package is appreciated, commits to vcs are freely welcomed, but before - uploading, please contact the Maintainer for the green light. +* Team in ``Uploaders`` is a weak statement of collaboration. Help in + maintaining the package is appreciated, commits to the git repository are + freely welcomed, but before uploading, please contact the ``Maintainer`` for + the green light. Team members who have broad interest should subscribe to the mailing list python-modules-t...@lists.alioth.debian.org whereas members who are only interested in some packages should use the Package Tracking System to follow the packages. ---------------------- -Subversion Procedures ---------------------- - -We're using a Subversion repository to maintain all the packages, then if you're not -already using it you will need to install svn-buildpackage. - -*The repository layout:* - -metainfo/ - Ignore this directory (reserved for future usage). - -packages/ - The source packages are here. - - package-foo - branches - If you or someone wants to play with a package possible breaking the trunk, give it a name and do it here. - tags - For each release, a tag. More information below. - trunk - That's where the main development happens, it should contain only the debian/ subdirectory part of a package. - -www/ - Documents and stuff that will be or are being published online in our website. - - -Hints: -====== -* To keep your package tree clean as pointed out above, always :code:`svn-inject` your packages using :code:`-o` argument. -* If you svn-inject'ed a package without :code:`-o`, you should remove upstream sources and run :code:`svn propset mergeWithUpstream 1 debian/`. -* Since you are keeping only debian/ directory in the svn tree, you need to put the 'package-foo'_'version'.orig.tar.gz in tarballs/ a directory above the package, and svn-buildpackage will do the merge for you. More information about this in the svn-buildpackage howto at /usr/share/doc/svn-buildpackage/. -* After upload, tag the latest revision running :code:`svn-buildpackage --svn-tag-only` into 'package-foo' directory. -* You can revert the changelog changes after tagging, running :code:`svn revert debian/changelog`. -* If you're a pbuilder user, you can invoke it using :code:`svn-buildpackage --svn-builder pdebuild <args>`. - -For more information on how to maintain packages within the repository with svn-buildpackage: -`http://pkg-perl.alioth.debian.org/subversion.html <https://web.archive.org/web/20141027193341/http://pkg-perl.alioth.debian.org/subversion.html>`_ - -Please note that python-modules URLs are different than pkg-perl ones: - -* svn+ssh://lo...@svn.debian.org/svn/python-modules/packages/ -* svn://svn.debian.org/python-modules/packages/ -* http://anonscm.debian.org/viewvc/python-modules/ +-------------- +Git Procedures +-------------- -Moreover, python-modules still use the default layout: don't pass :code:`-l 2` to :code:`svn-inject`. +As of October 9, 2015, the DPMT uses git as the version control system for all +packages, and git-dpm as the patch management regime. Details of the +procedures, standards for branches and tags, and common workflows are +maintained on the `Debian wiki <https://wiki.debian.org/Python/GitPackaging>`_ +page. ----------------- Quality Assurance @@ -127,7 +96,7 @@ packaging tools, etc. License ------- -Copyright (c) 2005-2015 Python Modules Packaging Team. All rights reserved. +Copyright (c) 2005-2015 Debian Python Modules Team. All rights reserved. This document is free software; you may redistribute it and/or modify it under the same terms as GNU GPL v2 or later.
pgp80vmBGfIrb.pgp
Description: OpenPGP digital signature
