[Soc-coordination] GCi, task ideas and whatnot

[Ana Guerrero]

Hi,

Thanks for working in this Gergely! 

On Sat, Oct 29, 2011 at 06:54:49PM +0200, Gergely Nagy wrote:
> 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.

For everybody interested in helping with code-in, we have 2 IRC channels
#debian-soc open to everybody (students welcome!)
#debian-mentors-soc open to mentors and for talking only about things 
that should not be talked in the open channel. (It is password protected,
ask for the key via query).
Please join there and ask any question you have.

A quick comment about the difficulty of the bugs: students will generally 
need 3 times the time you need to do something and most of the time with 
external help. Some of them, will be only interested in doing the minimal
tasks to get the t-shirt from Google.
(OTOH, there are some wonderful students that are the exception here.)

Some comments about the tasks:

> 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.


>From experience from last year, the first thing students interested in this 
task will want is a list with these packages. It might be a nice idea
providing it.
Also, I am afraid some maintainers won't welcome the patches or will complain 
about the quality. While not nice maintainers it is something we can not solve
from here, we could tell the students to add some blurb in their bug reports
about they participating in the code-in and some link about what code-in
works.



> 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.

Don't we have people with scripts doing this?

> 
>  * 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.

I think we have a team of people mananing the bugs against "unknown-packages",
it might be good asking them about this.


> 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.

This might work, but it would be just one task.


> 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.

We have some automatic list already using some metrics to check this
automatically. I am unsure student's knowledge of Debian, licensing and
free software will be enought to help with this.


> 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.

Yes, this one can work. We have a student last year adopting later 
the packages he improved in a QA upload during the code-in


> 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.

For orphaned packages, yes.


> 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.

I am missing from the list at least some translation tasks, weak point: 
you need mentors with different languages involved here.


Thanks again!
Ana

PS: I wrote this email in a hurry, please let me know if I wasn't clear
in some point.