On Sat, 02 Jun 2012 22:57:01 +0200, intrigeri wrote:
> [1] https://wiki.debian.org/Teams/DebianPerlGroup/OpenTasks
>
> I'm a recent member of the team, so the fact I lack much of the needed
> background probably explains that, but I felt like I should point out
> that some parts of this page make little sense to me. Or, perhaps
> better said, some tasks description are not clear enough to allow me
> to know if I'm the right person to do the task (so probably I'm not?),
> what's the next thing to do and where I can find more information
> about it.
I'm not surprised :(
This page is kind of a "scratchpad" to quickly drop ideas, and indeed
often they are not very clear. Which kind of defeats the idea of
using it as a common work plan.
> We can even consider this as a great time to prepare, collectively,
> our upcoming "use perl;" meeting at next DebConf! Starting this
> meeting with a clear, up-to-date view of what we need to do will
> probably contribute to a more fun and efficient meeting time :)
Definitely, and it's great that you are pushing this - thanks a lot!
(Besides the pkg-perl BoF it's also good for using it as a workplan
during DebCamp).
> I'll be happy to integrate useful answers I get over email to the wiki
> page, but don't hesitate doing it yourself :)
I'm staying with mail now, since my quick edits yesterday haven't
helped much :)
> * "wheezy freeze and package updates": I don't know what this is this
> about. Trying to guess, it might be about "shall we upload new
> upstream versions to sid during the freeze", or about something
> totally different.
Exactly.
Cf. https://lists.debian.org/debian-perl/2010/08/msg00038.html point
4 (from the pkg-perl BoF 2 years ago)
> * "there are some packages that still need adjustment": mentioning
> a few example ones would be much welcome.
True.
Not sure if anybody knows them; otherwise this task can probably be
deleted.
> * "Rewrite packagecheck (in Perl, modular, maybe not only for
> pkg-perl; see also below) (jeremiah)": it's not clear what "bellow"
> means in the context of a large wiki page. If I'm guessing right,
> I suggest "see the section dedicated to packagecheck bellow".
Yup.
> * "forward all (non Debian specific) patches upstream": have we means
> to list patches that we did not forward upstream yet? (yeah, I could
> probably hack a quick one-liner myself, but if it already exists,
> I'd rather use it)
I don't think there's anything ready-made yet.
I've just used 'grep "Forwarded: no" */debian/patches/*' last year to
find a first bunch but that has room for improvement :)
> * "Policy 3.8.4": as far as I can tell, neither the Debian Policy nor
> the Debian Perl Policy have a 3.8.4 section, so I'm at a loss.
That referred to the then-new Debian Policy version 3.8.4.
But I think we've given up on the idea to update all packages just
because a new Debian Policy version is released :)
> * "Next alioth project member ping": what does this mean?
In the pkg-perl project on Alioth we have 206 members, and some of
them were already inactive before I joined the group :)
The idea was to send a "ping" ("Do you still want to be a member?")
to those who haven't done something for $time, and remove those who
reply with "No" or who don't reply. In order to get a more realistic
picture, and maybe also to remove unnecessary permissions.
Ansgar has run such a "ping" once (only for non-DD group members,
IIRC), and this is a reminder to do it again.
> BTW, perhaps recurring tasks could be moved to a dedicated section.
> What do you think?
Good idea.
> * perl 5.12 and 5.14 transitions: "change some (build) dependencies
> later (should be done, is there something left?)" --> how can
> I check if there is anything left, and know if I can remove this
> action point?
This is about the alternative dependencies in the form
"libFOO-perl (>= x.y) | perl (>= 5.1x)"
that can be turned around once perl 5.1x enters unstable, as has
happened for 5.12 und 5.14.
So this is a simple grep + sed or similar over all our packages and a
friendly mass-commit.
(Also kind of recurring, just the versions change)
What's missing is the also kind-of-recurring task:
* Lenny is archived, update (build) dependencies. No need for
perl (>= 5.10.1) | libFOO-perl ()
or versions on packages that are already satisfied in Squeeze.
(cmd fix dpkg-control can probably help, although it's a bit slow
for all packages ...)
> * "Check the documentation on our website." --> check for what?
Up-to-date-ness, correctness, understandibility, ...
That's one of my points without any explanation :) I just wanted to
go through all docs and see if they still apply; my hunch is that
some things have become outdated and should be updated or removed.
(Like quilt with ancient debhelper versions etc.)
> * "Policy 3.9.1 (and base-files) has introduced
> /usr/share/common-licenses/GPL-1. #436105" --> so what? I don't see
> what's the next thing to do on our side.
The question was if we want to update all links in d/copyright at
once or just when we work on a package.
I guess reality has opted for the second approach and we can remove
this item.
> * "Finish uploading packages where the version in the archive doesn't
> have the group as the maintainer (i.e. adopted packages etc.) (is
> there something left?)" --> how can I check if there's
> anything left?
Hm, should be possible to compare the packages in git with Sources.gz
and check if any of the packages in our repo still has a version in
the archive which has the old maintainer.
> * "After the alioth changes: what needs to be done? (Vcs-* headers?
> documentation? website? scripts?) (is there something left?)" -->
> here again, I find it hard to finish work that's been done at 98% by
> others, without indication of what may be left to do.
Well, that's the problem here -- it's just a question if someone
still has an idea about what needs to be done :)
(Probably not since it's over a year ago.)
> * "Multi-arch / cross-building (?)" --> what's the next thing to do?
> Check if and how we're affected?
Yup
> * "PET3: maybe setup another instance (fallback?)" --> why? merely as
> a backup, as suggested by the "fallback?" word? any more reasons?
--> Ansgar
> * "PET3 on Alioth; first talks pet-team - alioth admins; should happen
> ~ end of August 2011, but didn't" --> status update?
--> Ansgar
> As a conclusion, perhaps we should reorganize this page by putting
> aside:
> * the tasks that must be done by experienced team members, or
> finished by the ones who started it (e.g. all the unclear "is
> there something left?" kind of tasks)
> * the tasks that can be done by newcomers in the team.
Regorganizing the "Packages/tools" section of the page seems like a
good idea to me; I'd rather divide it by type of action (like the
recurring tasks you mentioned above) than by target group. If the
items become clearer, I think everyone can perform them.
Again, thanks a lot for this initiative!
Cheers,
gregor, who has just added links to subpages at the bottom
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Larimar: Step through Black
Attachment:
signature.asc
Description: Digital signature