[Soc-coordination] GCi, task ideas and whatnot

Gergely Nagy algernon at madhouse-project.org
Sun Oct 30 11:52:14 UTC 2011


Ana Guerrero <ana at debian.org> writes:

>> dpatch->quilt
>> =============
[...]

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

I'll post a script to gather the list in a few minutes.

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

Either that, or maintainers can be asked beforehand, if they'd accept
such a patch, and if not, then go for another package.

(And for the record, there are packages that build-depend on dpatch, but
don't even use it: these would be trivial targets, and would still be
useful, imo ;)

>> Handling bugs filed against unknown packages
>> ============================================
[...]
>>  * 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?

I don't have any scripts. :P

And as far as I know, noone's working on the backlog at the moment. I
monitor new bugs, and have plans to work the backlog too, but I'm not
quite there yet.

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

I am that "team", and I do not know of any scripts that'd help me. There
might exist some, in which case a task would be to find them. And that'd
be either an Outrach or Research task (/msg tbm Can I have your
unknown-package scripts, if any?) *nod*

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

Fair enough.

-- 
|8]



More information about the Soc-coordination mailing list