[Soc-coordination] GCi, task ideas and whatnot

[Gergely Nagy]

Hi!

First of all, apologies for the mass-CC, I figured that since most
everybody else did do the same, so will I. But this is the last message
I Cc (unless someone explicitly requests further CCs), the rest I'll
keep to the soc-coordination@ list (M-F-T set appropriately).

Since - as far as I read - we already have a volunteer for the team lead
(\o/ Obey Arthur Liu), I'll try to focus on areas I hope to be useful:
coming up with tasks.

I admit, I haven't read everything I need to know about GCi yet, so some
of the things below might need some beating into shape to be useful.

Anyway, for the past few days, I was trying to come up with a few easy
hacks that could be turned into tasks, something that someone completely
new to Debian could successfully complete (with a little help, of
course), would be useful for Debian as a whole and perhaps would make my
life easier aswell.

So, here's the list! (The descriptions obviously will need some work,
I'm merely dumping ideas here)

dpatch->quilt
=============

Category: Code
Difficulty: very easy

The task would consist of migrating packages from dpatch to something
else (preferably quilt). Most of this can be easily done very easily,
and could almost be automated (there's even scripts to help one do
this), but manual review is still highly preferred.

The goal would be to convert a handful of packages, and submit bugs
to the BTS.

While working on this task, one would learn a couple of tools related to
Debian package building, and would learn a lot about packaging in
general aswell. But extensive packaging knowledge is not needed for the
task.

There are many packages still build-depending on dpatch (I can provide a
list, too, if so need be), and it's very easy to choose a couple of easy
ones.

An added benefit of this task is that multiple people can work on it
simultaneously, thus increasing the benefit for Debian.

Handling bugs filed against unknown packages
============================================

Category: Code/QA
Difficulty: easy

There are a few subtasks within this task, as handling bugs filed
against unknown packages involves a few different things (and there's a
huge backlog too!):

 * One subtask would be to go through the backlog, and close any bugs
   that have been triaged before, and can be safely closed (ie, the
   package is no longer in Debian, neither in stable, nor unstable).

   Participants going for this sub-task would be advised to first
   assemble the list of bugs to close, before actually closing them.

   The benefit of the subtask is that the number of open bugs could be
   decreased significantly.

 * Another subtask would be to triage misfiled bugs, that weren't
   responded to yet. Find out if the bugs need to be reassigned (typos
   in package names, etc), closed (package not in Debian) or whatever.

 * The last subtask would be a bit of coding: writing scripts that would
   assist one in determining what to do with a misfiled bug:

     - It would check incoming.d.o
     - It would check the removal logs
     - Bonus points if it recognises kernel images, and suggests
       reassigning the bug to src:linux-2.6 :>
     - The handiest part would be if it would check a few other, known
       repositories (ubuntu, debian-multimedia, oracle [virtualbox]),
       and see if the package exists there.
     - It could also look for garbage before or after the package name
       (I've seen many bugs get misfiled due to the Package: name header
       having an unbreaking space after the :).
     - It could check whether parts of the Package line are valid
       package names (I've seen stuff filed against "package in squeeze
       (amd64)" or similar, which end up getting assigned to the
       appropriate package AND 3 other, unknown packages ["squeeze",
       "in" and "(amd64)"])
     - Detecting typos in package names would also be grand.

   This coding task is a bit vague, and there's many many things the
   tool could do. I'm happy to come up with a better description, if you
   all see value in it.

usercategories documentation
============================

Category: Documentation
Difficulty: medium

I "recently" discovered usertags, and while they're pretty simple, and
reasonably well documented, the documentation on usercategories
is... lacking.

Researching and documenting this part of the BTS would be welcomed by
many, I assume.

Cleaning up QA-maintained / orphaned packages
=============================================

Category: QA
Difficulty: medium

This is another vague task, and could perhaps be split..

One thing that I would find useful, is finding packages that are no
longer relevant. Packages that are abandoned either upstream, or in
Debian (or both), have little to no users, and better
alternatives. These could be removed from the archive.

Another thing would be upping the quality of orphaned and QA maintained
packages: these are often in a very sorry state (like, debhelper compat
level 2 sorry) and if we want to keep them in the archive, they could
use a serious face lift.

The task in this second case would be identifying such packages, and
bringing them up to speed: format 3.0 (quilt) and debhelper updates,
where appropriate.

The list is fairly long, and there's lot of packages to choose from.


Well, these would be my ideas so far. I'll read up on GCi in the next
couple of hours, and will try to update this list based on what I find
out.

-- 
|8]