2722
Comment: add perl vs. perl-modules; dh-make-perl bugs link
|
3718
add link to minutes from DebCamp 2009
|
Deletions are marked like this. | Additions are marked like this. |
Line 12: | Line 12: |
* [[http://lists.debian.org/debian-perl/2009/07/msg00037.html|Minutes]] from the first meeting at DebCamp in July 2009. | |
Line 16: | Line 17: |
* Investigate possible migration from Subversion to Git. * (build-)depending on perl or perl-modules |
* Investigate possible migration from Subversion to Git. → Going forward, although nobody here has really worked on a project with thousands of Git submodules * (build-)depending on perl or perl-modules → We should drop the >=5.6 version requirement on perl, and just specify the versin where there is a real requirement. The oldest available release (in oldstable) is 5.8.8 or so |
Line 25: | Line 26: |
* Clean up the "New Packages - Work in Progress" (i.e. never uploaded) list of packages in PET. * Review the "Newer upstream available - Work in Progress" section in PET and file ITPs for missing packages etc. * Rename all source packages to lib*-perl. |
* Clean up the "New Packages - Work in Progress" (i.e. never uploaded) list of packages in PET. → gregoa has done it in the past, should be a periodic rite * Review the "Newer upstream available - Work in Progress" section in PET and file ITPs for missing packages etc. → Add a section for packages that are pending and that have not been touched for too long * Rename all source packages to lib*-perl. → Check with ftp-masters whether it is as easy as uploading the new packages. Seems basically trivial. |
Line 30: | Line 31: |
* forward all (non Debian specific) patches upstream and add the CPAN RT ids to the patch headers * maybe we need a tool? |
* forward all (non Debian specific) patches upstream and add the CPAN RT ids to the patch headers → This can follow DEP3 once it is accepted * maybe we need a tool? |
Line 35: | Line 36: |
* Policy 3.8.1: mass update packages? | * Policy 3.8.2: 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. |
Line 38: | Line 39: |
* remove transitional dummy packages | * remove transitional dummy packages → Who is tracking them? We have to identify them |
Line 40: | Line 41: |
* Upload all half-adopted packages (rationale: old maintainers don't want to get bug reports, we do) | * Upload all half-adopted packages (rationale: old maintainers don't want to get bug reports, we do) → Every adopted package should warrant an immediate upload, as it carries important informations. |
Line 49: | Line 50: |
== Others == Topics that don't fit in the above categories. * debian/copyright: * boilerplate for reference to changelog * mechanism for members to accept this procedure |
→ Damyan is "slowly" (quoting him) but steadily achieving this; he strongly invites us all to participate |
Debian Perl Group - Open tasks
This page collects ideas for tasks within the Teams/DebianPerlGroup. These tasks can be worked on at DebCamp or might be tackled by volunteers "at home".
History
The previous list of tasks on this page has been discussed during DebCamp in August 2008. The minutes of the meeting are available in the archive of the debian-perl mailing list.
Policy/discussion
List of issues that affect our work mode and need discussion.
- Investigate possible migration from Subversion to Git. → Going forward, although nobody here has really worked on a project with thousands of Git submodules
(build-)depending on perl or perl-modules → We should drop the >=5.6 version requirement on perl, and just specify the versin where there is a real requirement. The oldest available release (in oldstable) is 5.8.8 or so
Packages/tools
List of tasks that need to be performed on all/many of our packages; or maintainance tools ...
- Work out how the applications "branch"/git repo really works.
- Finish or just use the "unified" debian/rules (for packages with and without quilt).
- Create the header/identifier for debian/rules that allows mass-updates.
- Clean up the "New Packages - Work in Progress" (i.e. never uploaded) list of packages in PET. → gregoa has done it in the past, should be a periodic rite
- Review the "Newer upstream available - Work in Progress" section in PET and file ITPs for missing packages etc. → Add a section for packages that are pending and that have not been touched for too long
- Rename all source packages to lib*-perl. → Check with ftp-masters whether it is as easy as uploading the new packages. Seems basically trivial.
- Rewrite packagecheck (in Perl, modular, maybe not only for pkg-perl)
- Patches:
- forward all (non Debian specific) patches upstream and add the CPAN RT ids to the patch headers → This can follow DEP3 once it is accepted
- maybe we need a tool?
- patch naming convention?
- forward all (non Debian specific) patches upstream and add the CPAN RT ids to the patch headers → This can follow DEP3 once it is accepted
- Fix common lintian-errors repo-wide (e.g. errors from pod2man, missing patch descriptions, ...)
- Investigate possible migration from Subversion to Git.
- Policy 3.8.2: 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.
- Unify the various debian/repack.{sh,pl} scripts.
- Lenny is out!
- remove transitional dummy packages → Who is tracking them? We have to identify them
remove (?) B-D on "perl-modules (>= 5.10) | libFOO-perl"
- Upload all half-adopted packages (rationale: old maintainers don't want to get bug reports, we do) → Every adopted package should warrant an immediate upload, as it carries important informations.
dh-make-perl
→ Damyan is "slowly" (quoting him) but steadily achieving this; he strongly invites us all to participate