[Soc-coordination] Call for Projects & Mentors for Google Summer of Code 2012

[Niels Thykier]

On 2012-02-20 10:58, Gergely Nagy wrote:
> [...]
> 
>> Create Lintian reports frontend
>> ===============================
>>
>> The static package analysis tool, Lintian, is currently being run on
>> all packages in Debian.  It has a tool called "harness" to publish the
>> results of its quality checks on lintian.debian.org.
>>
>> Currently, "harness" is an "internal" tool to generate these reports,
>> but we believe it would be useful to Debian as well as its many derivatives
>> to have a propper tool for generating these reports.
> 
> s/propper/proper/
> 

Fixed.

>> The project will consist of two parts.  Part 1 will be to create a
>> black box test suite to test the current harness tool.  Part 2 will be
>> to rewrite "harness" into a proper tool.
> 
> I'd rewrite the above like this:
> 
> ,----
> | The project is made up of two parts: the first part is to create a black
> | box test suite to test the current harness tool, the second is to
> | rewrite "harness" into a proper tool that is usable without a pilot
> | license.
> `----
> 
> This means pretty much the same thing, but is more catchy, and easier to
> read, in my opinion. O:)
> 

Did that, still have to incorporate Ana's suggestion on the "expected
length" of these parts.  Maybe, "We expect the new harness frontend will
be most time consuming part."?

I added a """generate these reports (static HTML pages),""" based on
ana's suggestion to clarify we are not looking for a web-frontend, but
it might need some further rewording.  On a related note, posted on the
wiki[0].

[0]
https://wiki.debian.org/SummerOfCode2012/Projects#Create_Lintian_reports_frontend

>>  * Co-mentors:  Any takers? :)
> 
> I can help out, I think. My perl-foo is a bit rusty, and my gnuplot
> knowledge is non-existent, but apart from this, I should be okay.
> 

Regarding gnuplot:
The minimum is that the student does not break our data output files[1]
and the new frontend keeps updating them (like the old one does now).
That being said, if the student is interested we could use some code to
transform said datafiles into graphs.  Allegedly there is some code for
that, but I haven't seen it and it will need some changes if harness is
being re-written.

[1] Space separted format of:  "<timestamp> <data1> <data2> ... <dataN>"


>>  * Deliverables of the project:
>>    * New automated harness test-suite
>>    * New harness frontend
> 
> There's one thing missing from the description, and from the
> deliverables: a more newbie-friendly explanation of what the harness
> tool does. I'm not exactly sure about this, though, and I have no idea
> yet what I'd extend the description with, but I have this annoying
> feeling that keeps bugging me.
> 
> I'll get back to you as soon as I find out what I'm missing.
> 

Not sure if the "static html" part (see above) helps.  :)

>>  * Desirable skills:
>>    * Perl and POD
>>    * docbook (for the "User Manual")
>>    * Templates (such Text::Template or Template::Toolkit)
>>    * Black box testing (http://en.wikipedia.org/wiki/Black-box_testing)
>>    * Input sanitation.
>>    * Possibly some Make or some shell code (sh or bash).
>>    * Basic gnuplot knowledge (format of data files etc.)
>>  * What the student will learn:
>>      You will learn methods to reduce the workload when dealing massive
>>      data sets (via incremental runs).  You will learn how to do black
>>      box testing on "non-trivial" black boxes.
> 
> That's a lot of desired skills. I'd cut down the list, and move some of
> them to the what will learn section. Make and basic shell is something
> that can be learned in an afternoon, so while it's great if a student
> already knows make and/or shell, I wouldn't say it's explicitly desired.
> 

Thanks, I wasn't quite sure on that.  I revisited the list and realized
I have nothing on "git" nor "package building".  The student will need
some knowledge of those.  For "package building", the bare minimum will
most likely be needed for the test suite[2].  Do you think I should list
those?

[2] Enough to create a minimal (almost) lintian clean "empty/useless"
source + build the debs.  So dh7 (possibly with an override target or
two) + d/control, etc.

> Desired has a "you HAVE to know this" sound to it, even if it doesn't
> mean that, so a short list of must have skills is less discouraging
> towards a student.
> 

So generally, we should list the most important skills that we expect
the student to read up on?

> My proposed list would be:
> 
> * Desirable skills:
>   * Perl
>   * Black box testing, or willingness to learn it (<link>)
>   * Ability to write documentation (docbook and POD knowledge is great,
>     but can be learned along the way)
>   * Familiarity with any templating language (Text::Template, or
>     Template::Toolkit, or something else)
> 
> * What the student will learn:
>   You will learn methods to reduce the workload when dealing with
>   massive data sets (via incremental runs), while working on a tool that
>   is run on the whole Debian archive and is a key piece of our QA
>   toolset. You will be able to learn how to do black box testing on
>   "non-trivial" black boxes.
> 
>   Along the way, there's a possibility to learn a lot about Perl, the
>   POD and docbook documentation formats, gnuplot, make and shell.
> 
> Something like that... to make it more attractive to students (*I* find
> it attractive as it is, but I don't have to be persuaded :).
> 

Thanks. :)

~Niels