GSoC 2019 [Collect build statistics]

Fri Mar 15 01:14:09 UTC 2019

Dear Arjun,

(Sorry if some things repeat from what Umesh sent you. I have already
written the reply yesterday, but did not manage to come back online
until now.)

Thank you very much for your demo app.

On Wed, 13 Mar 2019 at 17:52, Arjun Salyan wrote:
>
> As suggested, I have made an attempt at a basic demo app:
> https://frozen-falls-98471.herokuapp.com
>
> Please review it and let me know if this seems fine. After applying any further inputs, I shall proceed with the documentation to setting it up.

Wonderful, thank you. (The review would usually also include review of
the sources, so that you can get further suggestions for improvements.
Since you provided just the link to the app, I'm only providing you
feedback based on that one.)

0.) I have some general suggestions about organisation/layout of the
first/entry page, but it's not relevant at this stage, and it's
something that can be changed easily at any time.

1.) There seem to be some issues with the database. For
"<server>/ports/ArpSpyX/" I get the following error:

MultipleObjectsReturned at /ports/ArpSpyX/

get() returned more than one Ports -- it returned 2!

Request Method:GET
Request URL:https://frozen-falls-98471.herokuapp.com/ports/ArpSpyX/
...

I assume that you would need to use a primary key to avoid such
problems? (Honestly I'm not entirely sure how this should work in case
some port Foo gets deleted one day, and another day another unrelated
software with that same name gets introduced. The primary key should
probably be a number, and then you would have a mapping between the
name and the number corresponding to the latest port. Not that you
should worry about such cases, but you should definitely not allow
your database to have multiple entries for a single entity.)

> It is not completely static. The port information is fetched from database and is not hard-coded.

Well done.

> What I did was to clone macports-ports, and used portindex2json.tcl to populate the database. However, the format of the json outputted by portindex2json could not be directly loaded into the database. I had to manually make it in the format of fixtures accepted by Django (and that is why only few ports are available), which means that portindex2json would also require some modification.

Now that you mention it I seem to remember some issues.
I found an email that was left unresponded and I didn't pursue on the
issue since:
    https://lists.macports.org/pipermail/macports-dev/2018-March/037726.html
We should try to get this fixed.

I'm currently not at home for another 11 days and have somewhat
limited access to both computer and internet etc., so I'm not sure if
I can check this before I'm back, but maybe someone else can also look
into it.

What you may try to do is write a few lines of python script to do one
single thing: parse the json file from portindex2json (with the
library) and print the info back to the screen (first just the name,
then add a few additional fields). I assume this will fail as well,
and you'll know at which entry (port) that happened exactly. Then
eliminate or fix that entry (and maybe open a bug report, or write
here in case you'll be faster than others investigating the issues).

Another option (or if json doesn't load at all) would be to do some
kind of bisection (deleting entries) until you find the problematic
entries.

Note that Heroku's free account will probably not allow storing the
full set of ports. I assume that some check like "if first letter of
the port name is alphabetically smaller than letter <X>" could do the
trick if you hit that limitation.

> The build history is hard-coded.

No problem at all. We didn't ask for a fully functional app :)

> Also I need suggestions here- what info is most important to be displayed on the port info page.

The precise representation might still need to be defined / discussed
/ changed later. I expect that after the first implementation users /
developers would come up with suggestions for improvements (which is
why it is important to deploy the first working app early in the
summer).

But here's my view of what I consider most important:

(a) I want to know if all the builds succeeded. If yes, I'm perfectly
happy with one single green check saying that
        version X.Y / revision Z / commit abcd
    was successfully built + maybe info whether it is distributable (=
Can it be downloaded?
    Sometimes licence prohibits distribution)

(b) If some builds did not pass, I want to know:
    - on which OS version it failed / did not build at all / is still pending
      (I would prefer some table representation with red / green /
yellow / gray / ... text or background)
    - what was the last version (and when) that was successfully built

I'm not sure what representation would work best to deliver that info,
but I would not worry about it too much for now. For start, even a
sequential list of all builds of that port on any given OS would do
the job.

Later on, maybe a matrix with OS version in one direction
(horizontally) and port version in other direction (vertically) with
green / red boxes and more info when you click on it.

In case that you need more realistic demo data, you can find the
attached quick-and-dirty sample script that parser json from
buildbot's API. It fetches just the last four builds. You could change
that, but please be mindful if trying to run the script on a
considerably higher sample. This script imposes quite some burden on
the buildbot master. For the real run we would probably ask Ryan to
extract the data. These data would only be useful if the sample set of
ports is high enough.

I haven't tested it since one year (and it would be nontrivial for me
to test it now), but I hope that it still works.

> For now, I could only figure out to show build history for different os. Am I doing it correctly?

We are usually not that interested in build history for a single OS
version (at least not as the main view).

> The installation statistics, which currently run independently would also be integrated with port-info in the new app.
>
> Also, I have used bootstrap for this demo app, is that fine or we need to go with something more powerful like angular or react.

My personal view is: whatever works for you.

That said, we had some additional internal discussion about the
frontend after last year's GSOC application period was over and there
was a suggestion that given the fast rate of changes in the frontend
land nowadays, we would like to avoid having to rewrite the
application every few months just because something became more
fashionable in the frontend world.

So we came up with idea that it might make most sense to make sure
that we end up with a very solid backend, and then provide an API that
would make it easy to retrieve the information needed to display any
given page. Then someone (either the one creating the backend, or
someone else) could write a completely independent frontend (separate
from backend) that would only call the api to display the information.
If the most fashionable frontend changes a few years down the road, or
the existing one no longer needs our needs, or starts looking too
outdated, it should then be trivial to rewrite just the frontend
without even touching the backend.

An additional advantage would be that we could in the future extend
the port command to answer queries like:
- Is this port known to build? (If it's broken for everyone, maybe I
should not bother building at all, and inform the user that breakage
is expected, and point him to the exact bug report.)
- How much time approximately does it take to build this port?
- What's the size of the installed port?
- Which port provides file X?
- If the port breaks for the user, it could automatically submit build
log (after the user agrees) and collect build failure statistics from
regular users.

Mojca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse-buildbot-logs.py
Type: text/x-python-script
Size: 6134 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190315/22946301/attachment-0001.bin>