summer of code 2013 proposal

[Henri Le Foll <lists@lefoll.eu>]

My first proposal can be found in :
http://lists.debian.org/debian-devel/2012/03/msg00536.html


I believe that the .dsc file of a package is generated automatically.
I think that some information should be added to it.


A Team field should be added to debian/control. (and also to the .dsc)
=======================================================================

   - I hope every package will one day belong to a team.

   - I think that each package in wnpp or rfa or rfh should belong to a 
team (other than QA).

   - This field could be optional before packages have to belong to a team.


A Package difficulty field should be added to the .dsc.
=========================================================

   - Some information about the difficulty to maintain the package can 
be automacally extracted from the source package and added to the dsc file.

   - this information could be then be seen in the wnpp mail, the PTS, UDD.



As I don't know how to implement those changes, I suggest to create a 
project for the 2013 summer of code.

Question
=========
I am wrong in saying that information like :

   - a source package generates only one binary package

   - debian/rules is trivial.

can be extracted automatically ?



Henri

P.S. Here is the an quotation from 
http://lists.debian.org/debian-devel/2012/03/msg00536.html

----------------------------------------------------------------------------------------------

automatically generated information about the difficulty to maintain the 
package
================================================================================= 

Three or more characters which could easily show the difficulty to 
maintain the package.
AA0 for simple ones.

This information should be generated automatically.

1. about the source package
----------------------------------------
A : a source package generates only one binary package
B : a source package generates multiple binary package
C : a source package contains multiple upstream source.
D : used for D-I (udeb)
E : a library
F : a daemon
G : part of the kernel

2. about the conffiles and the maintainer script
---------------------------------------------------------------
A : no modification from d-h
B : only one file like copyright or control need attention
....
E : non trivial maintainer script
F : very difficult maintainer script.

3. if the package need to follow some sub-policy
-----------------------------------------------------------------
O : none
A : java
B : perl
C : python