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

Minutes of the pkg-perl BoF at DebConf 10

Thanks to jeremiah and others we already have minutes (taken with
gobby) from our BoF yesterday.

I'm pasting the raw notes here, with some comments in between:

--- snip ---

use Perl;
Annual Meeting of the Debian Perl Group
DebCon10, 2010-08-06

0) Introduction round

Yes, this has happened :)

1) VCS - the annual svn and git question

a prerequisite: PET - Ansgar has a "half-working" variant with both
Git and Svn support

a parallel task: repository migration and migration of the workflow

Tim says he has given up on trying to get git to work. Not saying it
is impossible, just saying someone has to care about it. el_cubano
hacked a shell script to glue together half a dozen packages. His
package's upstream moved to it.

Jonas is a git fanboy. He really wants to continue working with git. 

Ansgar asks do we need checkouts of the whole tree?
D. Bremner: Yeah, we'd most likely need to do that.

D. Bremner says that if we want to get this work done we need to make
sure that pet works with git.

Jaldhar says there are other reasons to move. Git repos are more
compact on disk. Upstream developers seem to be moving to github.

Question: Where is the source code for PET.cgi located?
Answer: On alioth


Tim: If we can get the stuff we already have working, scaling it is
the next challenge.

Jonas volunteers for git hacking. 
David half-heartedly says "yeah, I'll help."

Matt was also interested, IIRC.

Please report progress to the mailing list.

2) "Letter to the Perl Community" about Module::Install?

dam: I brought this up last year and never did anything about it. I
think it would be a bit more polite to talk to the author first.
Issuing a "petition" is a kind of an attack

Yeah, I agree - a petition is kind of an attack.

Tim said that perhaps turning the article / issue into a positive approach.

Perhaps an article in a widely read perl forum pointing to best practices?
The debian ruby team has an open letter to upstream, perhaps we can
do something similar. Best practices would be good. Gabor Szabo is
always interested in getting debian checks into kwalitee.

dam: Is module::install still a burden?
Nobody says it is extremely painful, but people wouldn't mind if it

Summary: if someone cares to either contact upstream and/or write
some guidelines it's appreciated, but it doesn't have a high priority
for the group

3) Policy about supported versions / versioned dependencies

How long do we want to support packages? i.e. backports.
dam: Supporting old stable when not hard is preferred, until it hits archive.debian.org
Tim: maybe we should fix RC bugs first.
Ansgar: Aren't there plans to make backport an offical part of Debian anyway?
Jaldhar: My understanding is that backports is becoming official in
the sense of part of the official debian server farm, not necessarily
support. Rhonda on IRC confirmed this.
ansgar: But that means that the backport of debhelper is on the
official infrastructure, and I think it is okay to rely on that
version of debhelper.
Rhonda: Actually DSA asks for packages that people do want to have
installed on DSA maintained servers to be from stable or in

Committed in the meantime

4) squeeze is frozen! (How) Does this affect out work?
What happens now?
Should we move on full steam ahead? 

We probably should not be uploading new upstream versions.
Historically non-buggy modules, or other exceptions might be good
candidates to get release team approval. The worse thing that happens
is that they can say no.

Every change we throw at the release managers takes time away from
other more critical issues.

Jaldhar: One thing we ought to consider is getting Rakudo * in 

Do we still upload to unstable? Just stoping work doesn't make sense.

If in doubt, branch. That might be good because are we really going
to have to merge?

ansgar: Only updating in SVN will make testing hard when packages
require newer versions of other packages not in unstable.

- bug the RT only with important stuff
- continue uploading the unstable, maybe withholding/giving extra
  care to important packages
- if we need to get something into testing, creating a branch in svn

5) Work across packages, internal tools
(cf. list in wiki)

Has not been discussed, please look at

6) CipUX

Jonas: CipUX is a tool for LDAP administration. Used for a quite a
while. One maintainer upstream only. It might be nice to have another
- this tool is considered crucial in SkoleLinux. At the moment there
is no reliable tool for LDAP. If anyone is curious and willing to
help get it in CPAN then that would be very much appreciated.

That was a request from the skolelinux team. Having someone with perl
knowledge to help upstream CipUX would help skolelinux and thereby
thousands of schools around the world.

7) Other


Thanks to jeremiah and bremner for relaying questions from IRC

N-1) Todo

who does what when?
(--> put in wiki)

I'll link this mail from there as a start :)

N) Keysigning

Happened afterwards.
--- snap ---

Thanks to all who participated and contributed in this BoF!


 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-    BOFH excuse #399:  We are a 100% Microsoft Shop. 

Attachment: signature.asc
Description: Digital signature

Reply to: