compare fedora perl packaging policy
add Handling of removed packages
|Deletions are marked like this.||Additions are marked like this.|
|Line 46:||Line 46:|
|* Maybe add debian/source/local-options with unapply-patches and abort-on-upstream-changes to all packages? (packagecheck, see also below)||* Maybe add debian/source/local-options with unapply-patches and abort-on-upstream-changes to all packages? (packagecheck, see also below) -- might be unnecessary if dpkg changes its defaults, cf. recent (May 2011) [[http://lists.debian.org/debian-devel/2011/05/msg01130.html|discussions on firstname.lastname@example.org]]|
|Line 50:||Line 50:|
|* Handling of removed (from unstable) packages: remove from trunk or also from branches/tags? move to attic? something else? At the moment we are a bit inconsistent. -- There's also `rm-pkg-from-repo' in our scripts directory.|
|Line 68:||Line 69:|
|* multi-repo support?||* multi-repo support? --> already in PET2|
|Line 71:||Line 72:|
|* PET2 on Alioth?|
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 issues that affect our work mode and need discussion.
Maintenance of applications in the Debian Perl Group -- included in our Policy already, might need work
List of tasks that need to be performed on all/many of our packages; or maintainance tools ...
- Investigate possible migration from Subversion to Git (waits for report from investigators)
- Create the header/identifier for debian/rules that allows mass-updates. (diocles)
- Rewrite packagecheck (in Perl, modular, maybe not only for pkg-perl; see also below) (jeremiah)
- forward all (non Debian specific) patches upstream and add the CPAN RT ids to the patch headers; wait for DEP3 to be finalised? write a nice bug/patch forwarding helper tool; first versions of forward-bug/forward-patch exist (ghedo++)
we need a tool for easy editing of patch headers according to DEP3; first version of 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 ...
- Policy 3.8.4: mass update packages? Very old standards-versions might warrant (just for QA work) to be updated, as they were built with very old toolchains. We should at least check packages that have not been updated since Sarge release.
After squeeze: remove B-D on "perl (>= 5.10) | libFOO-perl"
- After squeeze: remove transitional dummy packages (and debian/TODO items for them)
- After squeeze: remove alternative dependencies / versioned dependencies that refer to oldstable (etch)
- Next summer cleanup (remove packages from svn that were injected but never finished for upload)
- Next alioth project member ping
perl 5.12 transition: fix bugs, change some build dependencies after 5.12 hits unstable (partly done)
Check the documentation on our website.
Policy 3.9.1 (and base-files) has introduced /usr/share/common-licenses/GPL-1. #436105
- Check RFP/ITP packages
- Finish uploading packages where the version in the archive doesn't have the group as the maintainer (i.e. adopted packages etc.)
Which tests do we run / which variables do we set? -> consistency over packages
Maybe add debian/source/local-options with unapply-patches and abort-on-upstream-changes to all packages? (packagecheck, see also below) -- might be unnecessary if dpkg changes its defaults, cf. recent (May 2011) discussions on email@example.com
- Check for duplicate packages in svn and git.
Read Fedora Perl Packaging Policy and compare with ours.
- Handling of removed (from unstable) packages: remove from trunk or also from branches/tags? move to attic? something else? At the moment we are a bit inconsistent. -- There's also `rm-pkg-from-repo' in our scripts directory.
- continue breaking it to isolated modules
- make POD coverage pass (by completing the docs)
- combine dh-make-perl's "refresh" with config-edit's update functionality
- discuss git support and way forward
- review the code that Jeremiah has written to see if it fits our needs
- suggestions for more functionality, feedback, etc.
(not exclusively a pkg-perl topic but still)
multi-repo support? --> already in PET2
- PET2: maybe setup another instance
- PET2 on Alioth?