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 /* http://pet.alioth.debian.org/ */ 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 disappeared. /* 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 http://lists.debian.org/debian-perl/2010/07/msg00041.html 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 backports. /* 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. /* Summary: - 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 works */ 5) Work across packages, internal tools (cf. list in wiki) /* Has not been discussed, please look at http://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks */ 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 MEDIA TEAM!!!!! 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! Cheers, gregor -- .''`. 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