perl: squeeze release, 5.12 transition, etc.

[Dominic Hargreaves]

On Sun, Feb 06, 2011 at 12:44:37PM +0200, Niko Tyni wrote:

> If we do any 5.10.1 changes before the 5.12 transition, those should go
> to the "normal" repository at
> 
>  git://git.debian.org/perl/perl.git

I guess it's not going to be worth doing an upload just for the libencode-perl
thing, but it could safely get included if there are other reasons to upload
5.10 to unstable.

> As for the 5.12 transition, I'm afraid real life is currently leaving me
> even less time than earlier for Debian work so I haven't really planned
> any schedule. If anybody else wants to coordinate this, I'm happy to
> help with the details.

I don't think I can commit to anything as large as overall coordination,
unfortunately, but I'd like to help out where possible. I guess the
areas I could help out in are bug triage, mass rebuilds, at least. Once
I've familiarised myself with topgit (or equivalent... more below) I guess
I'd be in a position to handle some more of the package maintenance.

If you'd be happy for me to go over the current bug list and do a bit of
categorisation/chasing/prodding etc as necessary I'm happy to. This would
be a good way for me to become familiar with the nature of the perl package
maintenance task :)

> Otherwise, I'll try to set up a rebuild environment again and see where
> we are with the FTBFS bugs and the like. While the rebuilds themselves
> don't really require much developer time, I fear I can't be very fast
> at sorting through the rebuild logs and filing relevant bugs.  I suppose
> this task could be distributed quite easily if there are volunteers.

I would be willing to take this on. Do you have any notes from when you
did this before which might help? Otherwise I'll just have a go from
scratch.

> Upstream is preparing to release 5.14 in a few months, so I guess it
> would be possible to skip 5.12 altogether. The release team might like
> this, as a major perl transition causes a lot of work for them.

Okay. I guess it would be worth doing some initial assessment of the
current state of 5.14 to get a feel for the likely issues, although
it's probably too early to commit to that. One thing I don't have much
of a feel for is how much demand there is to have perl 5.12 packages
available soon.

Presumably most of the work we'd do on 5.12 will be of use in 5.14
anyway, so we can be responsive to external influences here (demand
for 5.12 vs timescales for 5.14 vs release time transitions).

> Finally, about the packaging: I'm not really thrilled about TopGit and
> I've briefly looked for alternatives. The git-dpm package caught my
> eye, it's quite nice and simple to use. It doesn't keep history for
> each patch/branch, but I'm willing to live with that. However, I do
> like the current system of generating patchlevel.h (see perl -V) from
> debian/patches, and I haven't found a way to hook this into git-dpm.
> 
> If anybody wants to get rid of the TopGit even more than me, help and
> suggestions would be welcome :)

I have found topgit fairly opaque so far, but I've not really done much
with it beyond peer at the perl repository a bit. git-dpm (judging from
its web page) doesn't look much simpler to me; I guess I just need to
invest a bit of time getting my head round either system, but I'll hold
off until you decide whether to switch :)

An alternative to managing patches in git this way would be a more
traditional quilt-like scheme (I've switched a few of my packages to
3.0 (quilt) recently which I find offers a reasonably smooth workflow
at least for simple packages). Do you have a feel for whether that would
work well for perl (I assume there are reasons that you didn't go that
way when you set up the current system)?

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)