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

Re: Limiting piuparts results in DDPO

<A continuation of a topic on the best way to show the
newly-integrated piuparts results in DDPO>

On Sat, May 24, 2014 at 9:12 AM, Christoph Berg <myon@debian.org> wrote:
> ...it will probably make sense to directly show ...S, S2T, T, U, ... results.
> (Oldstable plus O2S should probably not appear there at all, as few
> people are going to care.)
> Not sure what the best output format is,...

Ok, we have two topics.

First - limiting sections. I still prefer using the p.d.o conf file to
eliminate anything involving out-of-support distributions. If that's
acceptable, we can move on.

For the next part, I'm going to need more fully fleshed-out requirements.

I can add something to the piuparts summary format to map to the
transition tags you mention. This could be a replacement of the
summary 'reporting-sections' with a reporting section path (this would
balloon the size of the file). It would be cleaner to add a fourth
parameters with the upgrade path to the summary entry.

But, upgrade path is not the only degree-of-freedom in the suite of
piuparts tests, and perhaps not the primary parameter affecting
developer interest. Should the output reflect, say, 'nodoc'? This
could be another 'tag' field in the summary. How many independent
variables should be reflected in DDPO? What are they, and how should
they be displayed?

If this extra information is being detailed, it makes less sense for
the summary to throw out all but one result per reporting-section.
Perhaps the summary format should be replaced with a detail of all of
the 'non-passing' (or is it 'failed'?) test results. And DDPO should
show all of them, in the table cell and/or tool tip.

If this is about hiding info that the maintainers do not care about,
should stable just be eliminated (with its 6 failed packages :-) )? Or
maybe flagged with a different color? (Sounds like this is perhaps a
third topic - displaying priority information).

Do PTS considerations affect any of this?

As to my position, the existing format is what I wanted to see. A
failure is a failure, and I'm happy with being directed to the
'worst'. But, I'm willing to code to consensus. I just need to fully
understand what that is.

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

Reply to: