[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Perl Group meeting at DebCamp - 2008-08-06

On Tue, 05 Aug 2008 23:36:53 -0300, gregor herrmann wrote:

> now that a couple of members of the Debian Perl Group have arrived at
> Mar del Plata, we [0] propose to have a meeting for discussing some
> points in real life.
> When: Wednesday, 2008-08-06, 11:00 (UTC-3)
> Where: Salón de Mar ("larger talk room", 7th floor)

And the meeting has happened!
Thanks to everyone attending live or via IRC.

Here come the minutes:


Debian Perl Group Meeting

Live: Martín Ferrari, Frank Lichtenheld, Joachim Breitner, Tim
      Retout, Don Armstrong, Stephen Gran, Gunnar Wolf, Gregor
IRC:  Damyan Ivanov, Ernesto Hernandez-Novich, Jeremiah Foster

DebCamp, Mar del Plata
2008-08-06, 11:00-12:30

We more or less followed

Build system - debian/rules
* dh7 seems like a good recommendation.
* The features used need to work with the dh7 version in lenny.
* We can start to use dh7 now since lenny is frozen.

Patches against upstream source
* The attendants consider quilt the recommended way to go.

Should we package only modules or also applications?
* Some people might be interested in packaging perl applications too.
* The consensus was to put applications "somewhere separate".
* Someone [tm] needs to start the initiative.

debian/rules again
* For mass-updates it would be nice to have the information about
  which debian/rules-template is used. Ideas:
  - add a "header" to debian/rules, containing some unique identifier
    e.g. the version number of dh-make-perl
  - save the  md5sum of the used template somewhere
* debian/rules and quilt:
  - the debian/rules template could find out the need for including
    quilt stuff itself (and fail if there's no build dependency on
    quilt), so we'd have a template for quilt- and non-quilt packages
  - some external script for check quilt/patches

Source format 3
* A question for the future (it's not yet accepted in the archive).
* The switch -- if we want it -- will be easy with quilt.

Revision control system
* All attendants are satisfied with subversion for our purpose.

Do we take development versions from CPAN?
* qareport shouldn't show them anyway.
* Decide on a case-by-case basis -- if there is a reason, take it.

* The group is no legal entity and therefore cannot be the copyright
* "The superset of the module license and the Perl license" seems
  like a good default licensing for debian/*.
* Create a boilerplate that refers to changelog for the contributors.
* Ask contributors when joining the group to accept the "default
  mechanism" and keep gpg-signed mails.
* Optionally add yourself to debian/copyright if you see fit.
* The new format is machine-readable not writeable, so no automatic
  conversion. A parser might be nice.
* We change dh-make-perl to output the new format.
* It's encouraged to change to the new format when updating a
  package, and the new format is recommended for new packages.
* For adopted packages - depends on what we keep.

Migrations - debhelper/policy
* debhelper:
  - use lenny's dh7 version, bump manually only if needed
  - change later (lenny+1) automatically
* Standards-Version:
  - case-by-case decision about automatic/manual changes

Debian Policy 3.8.0
* Publish a template for README.source and add it to all packages
  that use quilt and don't have one.
* Apache 2.0 license in /usr/share/common-licenses

Freeze & new upstream versions
* Let's go on integrating new upstream releases.
* In case of uncertainty: please ask.
* In case of certainty (that a new upload would disturb the release):
  please put a note into the changelog.

Adopting packages
* If we use shiny new templates repackage follows logically.
* Of course we keep changelog and copyright.
* Todo: Write a "How to adopt a package".

dpkg-shlibdeps warnings
* If it's in Makefile.PL, patch it, otherwise (third-party) probably
  not worth the hassle.
* Report the bug upstream if applicable, of course.  
* For later inspection: keep logs? svn-buildstat? let dpkg-shlibdeps set a flag?
  mass rebuild? build machine?

* Let's fix them!
* We have many old minor bugs open, we need somebody to triage them.

* qareport could show a warning if debian/watch uses a non-dist URL.
* Let's replace all by-author/by-module URLs.
* It's possible to put 2 URLs in debian/watch in case the dist-based
  URL is not the "best".

Use dh_lintian?
* Integrated in dh7.

Convert packages to quilt
* Already done for (almost?) all packages.


If you have participated please correct any errors; if you haven't
please feel free to comment on any of our ideas, they of course can't
be authoritative.

gregor & gwolf

 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-    BOFH excuse #19:  floating point processor overflow 

Attachment: signature.asc
Description: Digital signature

Reply to: