[Reproducible-builds] Applying to Outreachy to work on Reproducible Builds

[Holger Levsen]

Hi Val,

On Thu, Mar 24, 2016 at 10:57:03PM -0400, Valerie R Young wrote:
> >(And you should have a local testbed anyway, to be able to develop+test
> >your code. As its mostly about the webpages, you also dont need jenkins
> >for that nor do you need to be running tests. Just experimenting with
> >the existing reproduicble.db should be fine.)
> I assumed I would be testing things locally -- I have a pretty light laptop
> (asus zebook) but I doubt it'll give me trouble given the size of the
> db/website. I might have trouble if I branch out to more computational
> intensive work..?

I think for testing changes to the website a light laptop is definitly
suitable. There are no big computations being done, just creating all
the webpages might take time, but you rarely need to create them all.

You might need some diskspace though, I'm guessing 10GB should be enough
(maybe less) if you just have test data. (Mattia, how much diskspace does your
test setup use?)
 
> I looked into your suggestions (see below) and added the ones I don't think
> I'll get to to the timeline!

cool!

> Status update:
> The online Outreachy application has been updated. All that is left is the
> contribution! Notes/questions about your (Holger's) suggestions for
> contributions (copied from private email):
> 
>   (1) convert bin/reproducible_html_dashboard.sh into python (and/or do the
>     above changes suggested by Lunar to the dashboard)
>   (2) convert bin/reproducible_html_pkg_sets.sh into python
> 
> I don't actually think I have enough time to do one of these conversion, due
> to the business of this next week (I'm going on a long weekend trip
> tomorrow) and my only basic familiarity with python and bash scripting.  Ran
> into some file location expectations when trying to run
> reproducible_html_dashboard.sh -- but I'll ask about this when I actually
> get to working on it!

you need to install things in /srv/jenkins/

I think an awesome initial contribution would also be to set up such a
local test setup *and document the needed steps*. (First in the wiki is fine,
but this should really go into INSTALL or CONTRIBUTE in
jenkins.d.n.git.)
 
>   (3) enhance bin/reproducible_json.py to create include an arch agnostic
>     summary. currently the json will have results for amd64 and armhf, but
>   its not clear which is authorative. the result should be: if it fails in
>   some suite/arch combination, the result should be failure.
> 
> I'm pretty sure that I can do this quickly enough :) I've run the script on
> reproducible.db and it looks like we only need to do a little extra data
> munging. But I'm confused about the goal:
> - Do we want an additional json file to be published, with information about
> whether the package succeeds across all architectures? Who is going to do
> anything with that file?

one of the json files (we have two) is used by eg tracker.debian.org as well as
ddpo.debian.org and probably others. the other is to be used by
individuals who prefer to parse json over downloading the sqllite db and
use that.

that seperation has historically been created and is maybe not the best.

> - Or do we want to write an "arch agnositic" summary to reproducible.json
> instead? Should the "architecture" key be blank or non-existant? (I haven't
> looked into to whatever is using this file)

that. 

there should be an arch agnostic summary plus specific information for
each arch.

we do have two json files though: reproducible.json has all the
information about all suites, while reproducible-tracker.json only has
data for unstable. *Probably* the arch-summary should only be given for the
rb-tracker.json, maybe only the arch-summary?

rb-tracker.json should also exclude the "not-for-us" status as this is a
deficiancy in our test setup and should not be displayed on trackers.

OTOH, if it fails somewhere, it should be displayed on trackers even
if's that package is nicely reproducible somewhere else. (Though for
trackers we just care about unstable & maybe experimental.)

We got consumers for the json data faster than we could create a
coherent design :/ :)


-- 
cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160329/13529df4/attachment.sig>