add lsdiff hint
|Deletions are marked like this.||Additions are marked like this.|
|Line 27:||Line 27:|
|* check that `.diff.gz` doesn't contain any direct changes to the upstream files (they will end up with some ''mess'' on the repo); if you need to change them, use a patch system;||* check that `.diff.gz` doesn't contain any direct changes to the upstream files (they will end up with some ''mess'' on the repo); if you need to change them, use a patch system (hint: `lsdiff -z *.diff.gz -x '*/debian/*' | wc -l` should return `0`);|
How To Join DPMT & PAPT Teams
How To Contact Us
You can use this places to ask us questions about packaging (not programming problems, please, for that uses #python on Freenode network) of Python modules and/or applications.
Request Access to Alioth Teams
It's also nice if you can describe your request of joining, in particular what packages you want to maintain with us (is already in the team, new or such) and other things that may describe your interest in modules/apps stuff. You can also present yourself (after having requested to join) sending an email to the mailing list mentioned above, so the whole team knows you're coming.
Your request will be approved once an admin examines it; you'll receive notification when it happens.
Work With The Packages
There is already a guide about basic tasks with packages in DPMT/PAPT teams here (just replace python-apps with python-modules if you're working with DPMT instead of PAPT).
use -o option to svn-inject, this will avoid storing the upstream source code in the repo, but only the Debian packaging;
check that .diff.gz doesn't contain any direct changes to the upstream files (they will end up with some mess on the repo); if you need to change them, use a patch system (hint: lsdiff -z *.diff.gz -x '*/debian/*' | wc -l should return 0);
(as for the time being) it seems svn-inject still doesn't support format 3.0, so you have to prepare a 1.0 format source package, inject it in the repo, then re-convert it to 3.0;
Policy About Maintainer and Uploaders Fields
There is a unwritten policy about the usage of Maintainer and Uploaders field, you might be interested to know about:
If the team is in the Maintainer field (and you are in Uploaders field) then every member of the team can apply changes to the package and upload it freely;
if you are in the Maintainer field (and the team is in Uploaders field) then every member of the team can apply changes to the package but any upload should be acknowledged by you (there are some exceptions, like uploads to fix RC bugs, but are infrequent).
As a general rule of thumb, just set Maintainer to the team; there might be some exceptions, like in situations where the package is so complex that a check from a knowledgeable person is welcome before an upload but they are very rare.
Request For Sponsorship
There are several ways you can as for a review and (hopefully) for a sponsorship of your package: