new item: agree on branch names
suggest implementing hooks to enforce agreed branch naming policy
|Deletions are marked like this.||Additions are marked like this.|
|Line 21:||Line 21:|
|* Somewhat related: agree on branch names in git for backports, *-p-u uploads etc.||* Somewhat related: agree on branch names in git for backports, *-p-u uploads etc. (also add enforcing hooks?)|
|Line 28:||Line 28:|
| * check if the change happens in 5.14 or 5.16 => does it affect Wheezy?
* if 5.16, wait for Wheezy release and then NMU the packages that shall be updated (when we have patches)
* if 5.14, ???
|* deprecated in 5.14, removed in 5.16 => wait for Wheezy release and then NMU the packages that shall be updated (when we have patches)|
Debian Perl Group - Open tasks
It should have an up to date list of open tasks, please remove completed tasks; for documentation please add links to the History section below (instead of adding them in between the tasks here).
List of topics that affect our work mode and need discussion.
- Wheezy freeze and package updates: shall we upload new upstream versions to sid during the freeze?
See Minutes from the meeting at DebConf in 2010, point 4.
- Somewhat related: agree on branch names in git for backports, *-p-u uploads etc. (also add enforcing hooks?)
- Add handling of debian/copyright (Copyright-Format 1.0) to our group policy.
perl 5.16 transition: fix bugs: fix bugs and forward upstream, but the transition won't happen in unstable before Wheezy is released
deprecated in 5.14, removed in 5.16 => wait for Wheezy release and then NMU the packages that shall be updated (when we have patches)
List of tasks that need to be performed on all/many of our packages; or maintenance tools ...
Check the documentation on our website: go through all docs and see if they still apply [gregoa: first round done, handing over to intrigeri]
- Finish uploading packages where the version in the archive doesn't have the group as the maintainer (i.e. adopted packages etc.):
- build the list of such packages: compare the packages in Git with Sources.gz and check if any of the packages in our repo still has a version in the archive which has the old maintainer
- subscribe our -maintainers ML to the PTS of these packages so that we get their bug reports
- after Wheezy is released: upload these packages, eventually
QA: cast to pointer from integer of different size: file bugs/fix (http://lists.debian.org/debian-perl/2012/02/msg00029.html)
- find a co-maintainer for dh-make-perl
- continue breaking it into isolated modules
- improve POD coverage
- combine dh-make-perl's "refresh" with cme's update functionality
- Rewrite packagecheck (in Perl, modular, maybe not only for pkg-perl)
packagecheck provides some function of "cme check dpkg". It may be better to improve dpkg model taking into account our needs (dod)
- lintian checks or a lintian vendor profile or something similar; list things we could want to check here:
- uploading d/changelog with unresolved TODO / WAIT-FOR / etc.
(not exclusively a pkg-perl topic but still)
package PET for Debian, so that we can track bugs against it, and so that we can more easily get more instances running => we're less strongly affected by downtimes
- let's convince Arno to help us [David]
- Ansgar, what do you think?
- make it so some more of us have access to the box that runs our PET instance, so that we can repair it when needed
- on Alioth? first talks pet-team - alioth admins; should happen ~ end of August 2011, but didn't -- status update? [Ansgar]
- add features we need (Python)
- track patches
PET project's repo: git+ssh://git.debian.org/git/pet/pet3.git
- Check RFP/ITP packages
- Yearly cleanup (remove packages from Git that were injected but never finished for upload)
- Next alioth project member ping: send a "ping" ("Do you still want to be a member?") to those who haven't done something for $time, and remove those who reply with "No" or who don't reply. In order to get a more realistic picture, and maybe also to remove unnecessary permissions. Ansgar has run such a "ping" once (only for non-DD group members, IIRC), and this is a reminder to do it again.
When a new Perl hits unstable
Change some (build) dependencies ("libFOO-perl (>= x.y) | perl (>= 5.1x)" that can be turned around); this is a simple grep + sed or similar over all our packages and a friendly mass-commit.
Then fix all the "package-superseded-by-perl.html" Lintian warnings.
- "cme fix dpkg-control" should do this ...
When oldstable is archived
Update (build) dependencies. E.g. once Lenny is archived, there's no need for "perl (>= 5.10.1) | libFOO-perl ()" anymore, or to depend on versions of packages that are already satisfied in current stable.
- "cme fix dpkg-control" should do this ...
Things that would be nice to do, often repetitive. Can be done globally, or every time you work on a specific package.
- Forward all (non Debian specific) patches upstream and add the CPAN RT ids to the patch headers [tools: forward-bug/forward-patch exists (ghedo++), patchedit exists (jozef++)]
Fix common lintian-errors repo-wide (e.g. errors from pod2man, missing patch descriptions, ...) - some stuff fixed, other is more easily fixed by "dh-make-perl --refresh" on the next upgrade ...
Nice to have, some day
Write team-specific questions for NM templates (Enrico's mail).
- Random ideas: fix a Perl bug, update a Perl package to the group standards, adopt a package into the Perl group.
NM tasks for teams -- found in an even older mail from Enrico