[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