[Piuparts-devel] Bug#740386: Bug#740386: Bug#740386: Bug#740386: More robust piuparts results reporting format

[Dave Steele]

On Sun, Mar 2, 2014 at 9:57 PM, Holger Levsen <holger at layer-acht.org> wrote:
> control: tags -1 + pending
>
> + ...The names
> + "unstable", "testing", "stable", "oldstable", and "experimental"
> + have special meaning.
>
> yet this text lacks an explaination what the special meaning is. can you
> explain and add that please?!?
>

The current precise definition is a bit obtuse in this context - DDPO
sorts these strings, for use in a tooltip, in a particular order
relative to each other, vs. alphabetical for all others. It's a bit
presumptuous to say that in the README now, since DDPO does no such
thing yet.

The purpose here was to give a hint on a scheme for entering values.
The summary doesn't enforce a model, except for the reserved
'overall'.

To work with my current DDPO code, I could add something like "By
convention, the values [...] are expected here, though other values
can be used".

The real answer is that the "special meaning" is not yet defined. It
is dependent on how you want to use summaries. Last month, I would
have said that the 'special' values were required, at a minimum, to
populate the piuparts distribution table in DDPO. They dropped those
tables for other metrics in February, to reclaim space.

The current concept, defined by my DDPO patches, is that you have the
ability to control the distributions reported by the DDPO tool tip
from piuparts.conf, with the special sorting for the special
reporting-sections.

Another concept would be to limit DDPO to the special sections.This
would let you use other values to report other summary breakdowns to
other contexts. The 'overall' concept would need to be reworked a bit
here.

Which do you prefer?

>> 5892fca piuparts.conf.pejacevic: Add reporting-sections
>
> I don't like this patch as it hardcodes info which is also in the distro-info
> packages. Plus: why is it untested?

The point is that it is not hard coded. It's not necessarily
deterministic from distro-info. I can think of a couple of models for
assigning sections to distributions, and didn't want to hard code one,
or one mapping to distro-info. Do you map an upgrade test to the
newest dist in the list, or to more than one? Do you want all sections
to be summarized, per an algorithm, or just some, per a config? I
wouldn't be surprised to see the values here change.

Right now, if you don't define reporting-sections, you'll get an empty
global summary. Would you prefer a default? How would you see that
being calculated for the existing p.d.o sections?

It is untested because I don't have a cloned pejacevic environment.

>
> I've merged them all into develop now, except 5892fca. Plus I have pushed the
> branch but not yet deployed it.
>

Thanks

-- 
"Le mieux est l'ennemi du bien" - Voltaire