[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#792564: qa.d.o/dose: please export distcheck and buildcheck results in a machine readable format


Quoting Paul Wise (2015-07-17 06:06:23)
> > it would be useful to show information about unsatisfiability of binary
> > and source packages in DMD and the tracker. For that, qa.d.o/dose should
> > export machine readable data of the latest runs of distcheck and
> > buildcheck. I guess that the dose yaml format would be sufficient for
> > this.
> >
> > It would also be interesting if DMD and the tracker could link back to
> > the right page on qa.d.o/dose. For that purpose it would be useful to
> > have stable urls for a given source package which would then redirect to
> > the page of that source package with the latest timestamp. So then
> > instead of linking to:
> Stable URLs wouldn't be nessecary for tracker.d.o as the data can
> contain the nessecary URLs.

Correct. My motivation to add this was something I forgot to mention in my
initial report, but this is just an implementation detail: dose3 outputs its
results in yaml format. Implementation wise, it would be easiest if qa.d.o/dose
would just dump the raw data that dose3 generates in its own output format
without any further processing. That data then would of course not include any
urls and that's why I mentioned the stable URLs.

> Side note: I think the Perl implementation of unsatisfiability checks on
> qa.d.o has more human-readable results pages (but is more buggy).

I am fighting with "human-readable results pages" myself for years (See
http://bootstrap.debian.net/cross.html for example) and found that the
graphical display that Ralf created for qa.d.o/dose is superior to any other
that I have ever seen so far (including the Perl implementation on qa.d.o which
does not give me a proper explanation of the problem). If you know a more
"human readable" solution to display complex situations like this:


I would be all ears.

> At minimum, the short explanations on the architecture pages need to be
> present on the package pages too.

I think that would be a very good idea as well.


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: