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

Re: Debian Perl Group and DebC{amp,Conf}



Hi,

> In any case, you can add discussion items for the BoF at
> https://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks (and also
> work items for DebCamp).

The BoF did happen, and here are the minutes. Don't hesitate grep'ing
your name in there to fill your personal TODO list with anything you
committed to ;)

Agenda
======

 * Say 'Hi!' to the people folllowing along at home.
 * Who writes minutes, who monitors IRC (#debian-perl)?
 * [[http://www.dagolden.com/index.php/2098/the-annotated-lancaster-consensus/|The Lancaster Consensus]] and its relevance for us
 * Two years git - experiences, needs for clarifying, streamlining, improving workflows?
 one outcome of the discussion is 
 git import-orig --upstream-vcs-tag = ?
 bremner to think about "patches applied"
 * Debian Maintainers: the concept [[https://lists.debian.org/debian-devel-announce/2012/09/msg00008.html|changed]], do we want to revisit our policy of non-usage?
 * Low-hanging fruits meetings: spend a while together on many small tasks that take less than 2 hours each, and are waiting in the TODO list for too long.
    Proposal: have a low-hanging fruits meeting every second month, or every second month.
    Means and goals:
      1. Welcome newcomers <= have one or three experienced team members stay available to match tasks to people and answer questions.
      2. Direct communication & coordination between team members => light workflow, feeling that things are going smoothly.
      3. Get this warm feeling of working together (=> Feel Good™, get the motivation to tackle less fun tasks).
 * pkg-perl-tools package
 * lintian profile (see below)
 * Status report of the Perl 5.18 migration (\o/)
 * Ideas for Jenkins jobs?
 * cstamas agenda
 * add your items here. or above.

Lancaster Consensus
===================

http://www.dagolden.com/index.php/2098/the-annotated-lancaster-consensus/

General remark - need point of contact with the participants of the Lancaster consensus (toolchain mailing list?)

Minimum-supported Perl
----------------------

"the Perl toolchain will target Perl 5.8.1" -> Squeeze (oldstable) has 5.10.1, so we don't care.


Specifying pure-perl builds
---------------------------

In the general case, we have no reason to build pure-Perl versions of modules, have we?
In special cases, the consensus will make our life easier.

Environment variables for testing contexts
------------------------------------------

We probably should always set AUTOMATED_TESTING and NONINTERACTIVE_TESTING.
(in debhelper/cdbs ?! unless they are set already --> check --> debhelper doesn't)
EXTENDED_TESTING could be set when it's not too expensive, but careful, as any new upstream release can make it too expensive.
Other flags are likely not adequate for us.
EXTENDED_TESTING should be fine, perhaps unset it only on "slow" hardware? arm&co? Is there danger of enabling faulty tests via this and get FTBFS? +1, it should always be possible to specifically override any of them on a per-package basis

Proposal: since we are trying not to kill slow archs, maybe we could enable EXTENDED_TESTING only on test machines, and not on regular buildds?

Desirable ways of overriding EXTENDED_TESTING:

  * by package maintainers: should be possible to override on a per-package basis
  * by buildd maintainers: they should be enabled to override this variable globally at the scale of their buildds.

These variables could even be used Debian-wide.
-> Action: talk to QA folks (h01ger), buildd folks, debhelper & cdbs teams [Jonas]

Amendments to the Build.PL spec
-------------------------------

Seems not relevant to what we do.

Installed distributions database
--------------------------------

Seems not relevant to what we do.
How about supporting it? It seems that any such database will put stuff in @INC paths and will rely on the content. If we strip the info we'll break the database.
We're currently stripping packlists, a) because it's duplicating info for which dpkg is the canonical source, and b) because it's placing dynamically updated files in places where they're not supposed to be (correct me if I'm wrong on any of this). I think we'd have to see how the actual implementations will do things and whether such a database on Debian should include modules installed via dpkg or only those in the user's $HOME, for example.

user-installed modules installed with cpanm etc.?

Proposal: wait and see?
That's not implemented yet anyway.

Post-installation testing
-------------------------

Once this exists in the wild, we may want to build a bridge between DEP-8 (autopkgtest) and that thing.
How does this relate to archive-wide package rebuilds?
According to Lucas, no archive rebuild runs DEP-8 tests yet. Ubuntu is slowly starting to do it, though.
The way I read the Lancaster Consensus, Perl modules would just run their existing build-time tests again, so the results should be similar (modulo bloated systems) as for archive-wide rebuilds (but relevant test runs could be triggered by uploads)

Supporting DEP-8 (instead or in addition to CPAN post-inst testing) should be easy to implement via mass-commit for basically all our packages.

Enables users to run tests themselves.

Could run these tests (again) on rev-deps?

META file specification
-----------------------

* The 'provides' field -> not relevant to what we do, right?
* Improving on 'conflicts' -> once implemented in actual modules and then specified, we may want to use it in dh-make-perl.

Long-term goal for distribution-level data on PAUSE
---------------------------------------------------

Nothing is likely to happen on that front on the short term, and we probably won't be directly impacted anyway.

Case insensitive package permissions
------------------------------------

It shouldn't matter much for us.

Rules for distribution naming
-----------------------------

Standardization in this field might make dh-make-perl's job easier, but I'm unsure. We'll see what happens on the CPAN side.

Flagging abandoned modules and modules requesting help
------------------------------------------------------

Once this is effective, such flagging will probably give us good indicators.
E.g. we might want to be careful when shipping modules that are unmaintained upstream into stable Debian releases.

Automating PAUSE ID registration
--------------------------------

This will make it easier to join our team, no action required from our side.

Automating CPAN directory cleanup
---------------------------------

We probably don't care.

Module registration
-------------------

We probably don't care.


Two years git
=============

Experiences, needs for clarifying, streamlining, improving workflows?

* git packaging following upstream??
  git-import-orig --upstream-vcs-tag= makes it easy.
  See debconf-discuss recent discussion, it has more details about how this works. [abe can add that to the docs]
* At least one of us doesn't like not having the patches applied in the master branch.
  David Bremner will look at the workflows that do it otherwise
  => know what it would involve to go this way
* In our Git HOWTO, it should be mentioned that the mr config for new packages is dealt with by our script to create repos on Alioth. [abe can do] \o/

Debian Maintainers
==================

The concept [[https://lists.debian.org/debian-devel-announce/2012/09/msg00008.html|changed]], do we want to revisit our policy of non-usage?

Some our packages have DM credentials. This is a bug, isn't it?
What problem would DM things fix for us?

-> Action: email pkg-perl ML and ask if someone would profit from this [XXX: Who?]

If we use it, shall we ask the team before each time?

Actually no problem to solve yet, let's not use it, case closed.

Low-hanging fruits meetings
===========================

Spend a while together on many small tasks that take less than 2 hours each, and are waiting in the TODO list for too long.

Proposal: have a low-hanging fruits IRC meeting every month, or every second month.
    Means and goals:
      1. Welcome newcomers <= have one or three experienced team members stay available to match tasks to people and answer questions.
      2. Direct communication & coordination between team members => light workflow, feeling that things are going smoothly.
      3. Get this warm feeling of working together (=> Feel Good™, get the motivation to tackle less fun tasks).

Action: intrigeri proposes the date for the first meeting and suggests tasks.


pkg-perl-tools package
======================

Dam started compiling our group tools into a new Debian package called pkg-perl-tools.
Should make it easier for newcomers to get started.
Axel wants to join Dam in this effort.

Status report of the Perl 5.18 migration
========================================

Transition is ready to fire up. The most serious blocker is the Subversion FTBFS because of undeterministic parts in their Ruby bindings.
work is going on of fixing the upstream bigs revealed by 5.18
failing packages ordered by their rev-dep count: fsfs
new mass-rebuilds to be done

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712615
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.18-transition;users=debian-perl@lists.debian.org
https://wiki.debian.org/PerlMaintenance
http://www.larted.org.uk/~dom/tmp/5.18.rebuild-bugs.txt
https://wiki.debian.org/Perl518TransitionBugs

Ideas for Jenkins jobs?
=======================

h01ger wanted to run group-specific jenkins jobs. the more the better.
possible to rebuild after every push
action: XTaran helps integration 

lintian profile
===============

TBD
lintian supports additional checks that could be useful for introducing group-wide policy checks

cstamas' agenda
===============

* knowing the perl tools (used in the debian infrastructure) better
* keeping Mojolicious in debian uptodate
* promoting the use of it in debian
* making enhancement to the perl tools
   * first I thought about collecting best practices and recommendations
      * dam encouraged me to just do it  (aka. shut up and hack)
   * it seems (I hope) that I will be able to fix some problems related to packages.d.o

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc


Reply to: