RFH: Perl

[Niko Tyni]

[taking private mail to the list; I tried to cut out anything remotely private]

On Tue, Dec 30, 2008 at 03:53:13PM -0500, Guy Hulbert wrote:

> I've looked at the repo so I see perl releases and debian releases so I  
> have a vague
> idea how things should work.  I've also looked at the changelog.  My  
> first thought is
> what is the job to do here.  I see:
>
> - import and tag each new stable perl release
> - following each debian release, cut a new testing branch
> - fix bugs
> - improve the package
>
> So most of the work is the 3rd item.  Does 'triage' mean set priorities  
> ?  I suppose we
> are supposed to use the debian bug tracking system -- does my alioth  
> account work
> with that ?  I would guess that most coordination required is for people  
> to choose
> things to work on.

Yes, the 3rd and to a lesser amount the 4th item are the most work :)

The area we're currently doing worst is clearly bug handling. If you want
to help with it, you need to learn how to use the Debian BTS. You don't
need the alioth account for that, it's all driven by email and there
are no (technical) access controls.

The Debian Developer's Reference is probably a good place to start.

 http://www.debian.org/doc/developers-reference/

By 'triage', I mean testing if old bugs still apply or if they have
been fixed since, asking submitters for more information if necessary
and the like.

Most of the bugs are probably upstream ones that should be forwarded to
rt.perl.org (or rt.cpan.org for some dual-lifed modules). This usually
means more work than just bouncing the original report, like checking
if it still happens with current bleadperl and if it's already reported
upstream, digging for any other relevant information etc.

As a general rule, we don't want to divert from upstream any more than
strictly necessary, so the prime objective is to get the bugs fixed in
bleadperl (and ideally maint-5.10) first before including them in the
Debian package. These are the patches denoted by the substring 'fix'
in the debian/patches filename in the source tree.

There are also quite some modifications which don't make sense to
include upstream because they are specific to the Debian policy or
environment.  These are currently denoted by the 'debian' substring
in the debian/patches filename. Of course, making these configurable
upstream would be better so we wouldn't have to deviate, but nobody has
taken that task up yet (and it's probably non-trivial for many of them).

> I see the spam you mentioned.  It seems to be arabic and to have  
> attachments.  One
> can imagine all sorts of problems with that.  Can we easily get rid of  
> it (restrict to
> subscribers and prune abusers) ?

I just turned (silent) moderation on for non-subscriber posts, that
should improve things.

If somebody wants to help with the moderation, I'll happily share the
list admin password.

> Is Brendan still the maintainer ?

Yes, at least a co-maintainer [2], but he certainly has the seniority here.
Given his limited time, I've felt like the only Perl maintainer much of 
this year. Hence this call for help.

[2] http://www.debian.org/doc/developers-reference/pkgs.html#collaborative-maint

Hope this explains,
-- 
Niko