Some notes/TODO relating to perl interpreter maintenance.
http://lists.alioth.debian.org/pipermail/perl-maintainers/2011-February/001678.html is Niko's Feb 2011 post about work needed.
Dominic Hargreaves will coordinate the perl 5.12/perl 5.14 transition. Please use perl@packages.debian.org as the main contact point.
Work required before perl 5.12 can be uploaded to unstable
- Check whether it's sensible to upload 5.12 rather than wait for 5.14, given the transition pain. 5.14 due in April 2011
(see http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/Porting/release_schedule.pod)
- Look at likely issues for the perl 5.14 transition (will it be lengthy? If so, may be worth getting 5.12 done and dusted first).
- Rebuild environment for FTBFS bugs
- mass bug-file; ongoing
- Removal of things using perl-suid
- mass bug-file done, just a few left
Work related to perl 5.12 but not blocking it
- Mass-filing for deprecation warnings relating to dual-lived modules found in build logs
- mass bug-file done, ongoing
Mass-filing for other deprecation warnings (UNIVERSAL->import?)
- Close blocking RC bugs of dual-lived modules (Class::ISA, Pod::Plainer, Switch) (just after upload)
Transition bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.12-transition;users=debian-perl@lists.debian.org
FTBFS on sid bugs affecting rebuild: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.12-transition-ftbfs-sid;users=debian-perl@lists.debian.org
Perl 5.14 transition bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.14-transition;users=debian-perl@lists.debian.org
Perl 5.12 specific bugs: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=perl;dist=experimental
Perl 5.12 incompatibles: http://perldoc.perl.org/perl5120delta.html#Version-number-formats
Perl 5.12 deprecations: http://perldoc.perl.org/perl5120delta.html#Deprecations
Rebuilding packages
The main complication is that we need unofficial binNMUs of the perlapi-* and libperl reverse dependencies so that they can be used as build dependencies for rebuilding the rest.
The scripts at http://svn.debian.org/viewsvn/pkg-perl/scripts/perl-5.10-transition/perlapi.out?view=markup can be used to determine the necessary binNMUs; the order also matters because the dependencies form a chain.
Example: libdevel-caller-perl is needed by libdevel-lexalias-perl, libpadwalker-perl is needed by libdevel-caller-perl etc.
- set up an sbuild chroot with Perl 5.12 (note that debconf-english may need to be installed manually in place of debconf-i18n so that build-essential stays installable)
- convert an up to date perlapi.out into sbuild commands like
- sbuild -c exp -d unstable --make-binNMU="Rebuild for Perl 5.12" --binNMU=1 libgoo-canvas-perl_0.06-1
- upload the results into an unofficial repository (reprepro is a good tool; maybe the Alioth web space should be used to push these out to public?)
- file bugs for any failures
- once all the necessary binNMUs are uploaded, proceed to test rebuild all the arch:all packages (lib*-perl is a first approximation)
note that testing on i386 instead of amd64 would be better, as the use64bitint changes in 5.12 only affect 32-bit architectures -> better test coverage
- a 32-bit chroot and the schroot Personality option should be good enough on an amd64 host
Other issues
- Switch away from topgit, to git-dpm?
List based on http://lists.alioth.debian.org/pipermail/perl-maintainers/2010-March/001121.html
- BTS:
- categorizing and triaging bugs
- I think usertags could help here, we just need a sensible list
- closing invalid bugs
- Eugene has done a lot of this already, but I think there are still plenty left
- forwarding triaged bugs upstream if they're present on unmodified bleadperl
- we could definitely do better here; I'm personally erring much too often on the side of "I'll write a patch first" and then forgetting about it
- OTOH upstream has explicitly stated that documentation bugs should come with patches
- fixing the `real' Debian-specific bugs
- categorizing and triaging bugs
- Debian-specific patches (debian/patches/debian/*)
- document what they do, why they are needed etc.
- + possibly create one `divergence bug' per patch in the BTS to track this?
- ideally, find a way to drop them or integrate them upstream
- upstream has quite high standards so quick hacks usually don't make it in
ongoing work on dropping one: (568748); http://lintian.debian.org/tags/debian-rules-makemaker-prefix-is-deprecated.html
- document what they do, why they are needed etc.
- Alioth infrastructure:
- sending git commits to the PTS
- mailing list setup, spam filtering, moderation
- anything still needed?
- project web pages and other documentation
- other than maybe a basic jumping off point pointing to the wiki, PTS etc, what sort of things would go here?
- general peer review
- getting git commits via mail should help here
Generic tasks for a new upstream release
Updating Conflicts etc for dual-lived modules. Could a tool using Module::?CoreList help automate this? (http://lists.alioth.debian.org/pipermail/perl-maintainers/2010-March/001120.html)
We could also use an automatic tool to check that perl-base keeps being self contained, to avoid bugs like (479202) and (549170). (http://lists.alioth.debian.org/pipermail/perl-maintainers/2010-March/001120.html) Done in 5.12.0~rc3-1