This will describe the overall process involved in getting a new version (eg: 5.20.0) of perl into Debian testing. It is based on the perl 5.12 and perl 5.18 experiences, with some ideas for the future. These are only a rough guide; clearly each time round this process things will change and we will need to respond to new types of issues, but writing this down will hopefully save me and others time in the future.

PM = Perl maintainers

PTC = Perl transition coordinator (generally a Perl maintainer(s))

RT = Release team

  1. Upload development releases to experimental [PM]
    • Generally this should start around January, or when the contentious code freeze happens (TODO: check when this is likely to be based on perlpolicy.pod et al)
    • There are lots of things which need to be addressed as part of the perl package maintenance process; one thing which springs to mind is the assessment and possibly separate packaging of perl modules now marked as deprecated. It might be worth using a bug on the perl package to address this. See eg

  2. Package any deprecated modules separately. Depending on the stage of the release, it might be appropriate to stop them entering testing if the new version of perl is not targetted at the next release (ie we're "near" a freeze) [pkg-perl]
  3. Schedule rebuilds of XS modules using the process vaguely defined at PerlMaintenance and using scripts from;a=tree;f=perl-5.10-transition;h=e2e1c2f83718d47218adfc48b78d8259cdd42982;hb=HEAD - sbuild cribs available from Dom [PTC]

    • The aim here is to make as much of the archive as possible co-installable with the new release of perl, in a testing context.
  4. Overall assessment of rebuild: are there very wide ranging issues which need to be dealt with separately from bug filing on packages? [PTC, PM]
  5. Review previous usertagged transition bugs for issues which will crop up again, or module deprecation related bugs which will become serious.
  6. Ideally, make a testing archive available so that maintainers have a hope of reproducing the issues on their packages (for 5.12 and 5.18 this was only done on i386). Maybe we will have PPA equivalents at some point that will make this all easier. Dom has a reprepo workflow that can be cribbed from if needed
  7. File perl 5.xx specific (and optionally, non-specific) bugs at severity important. Look at; for some past examples [PTC]

  8. If there are new deprecation warnings (analyse the build logs for these) report these at severity minor
  9. Monitor bugs and triage/fix/supply patches as appropriate [pkg-perl]
  10. Implement a continuous, or at least period, rebuild of new upstream versions of packages to be rebuilt, as well as rebuilding packages when the FTBFS bugs in question have been fixed, to maximise the value of test repositories and maximise test coverage [PTC]
  11. At some point (when the binary module bugs are under control or at least aren't too horrific) do a full rebuild of anything which build-depends on perl or any perl modules. sbuild cribs available from Dom. File bug reports [PTC]
  12. When the fallout from the above looks like it's making progress, or when the .0 release appears, file a transition bug with the release team (example: suggesting a timeline for the upload of perl 5.18 to unstable [PTC]

  13. A transition tracker (eg will be prepared [RT]

  14. Mark any remaining FTBFS issues with rebuild-related packages as blockers to the release bug (whether directly caused by perl 5.18 or not [PTC]
  15. Prioritise fixing these bugs [pkg-perl]
  16. Ideally do a full test rebuild at around this point to get updated coverage and file any new bugs [PTC]
  17. At some point a few weeks away from the unstable upload, upgrade all the FTBFS bugs to serious, and the deprecation warning bugs to normal [PTC]. From this point on, new bugs should be filed as RC
  18. When the release team are happy (they will mainly be happy once the blockers are either zero, or can all be worked around) they will give the ack for an upload to unstable [RT]
  19. Upload to unstable and notify the RT [PM]
  20. The upload will be autobuilt as normal
  21. Once all (? define) architectures have built and installed versions of perl, the new version of perl needs to be actually installed on the buildds [RT]
  22. Then the release team will schedule the binNMUs needed to the necessary rebuilds to allow perl 5.18 to migrate to testing together with the other packages which depend on a specific major version [RT]
  23. Watch the transition tracker for new issues which need fixing [RT, PTC]
  24. Fix new bugs which might hold up the completion of the transition [pkg-perl]
  25. Once all rebuilds are complete (or at least most, and workarounds in place for the others, the release team will cause lots of packages including perl to migrate to testing [RT]
  26. Profit!
  27. In the past, a d-d-a mail has been sent at around this time with more info about the transition and how to tackle any perl related bugs which appear in the weeks/months after the new upload [PTC]