Re: Bug#908757: r-cran-processx: autopkgtest regression
Paul Gevers writes ("Re: Bug#908757: r-cran-processx: autopkgtest regression"):
> I really appreciate your comments.
Oh good! I sometimes feel we are talking past each other. I hope
it's not too frustrating for you.
> On 18-09-18 17:24, Ian Jackson wrote:
> > Paul Gevers writes ("Re: Bug#908757: r-cran-processx: autopkgtest regression"):
> >> On 18-09-18 14:23, Ian Jackson wrote:
> >>> How about a table:
...
> >>> passing failing
> >>>
> >>> r-cran-processx <version> <version>
> >>> autopkgtest (currenlty in testing) (currently in unstable)
> >>>
> >>> r-cran-processx <version> <version>
> >>> binary packages (currenlty in testing) (currently in unstable)
> >>
> >> The two above should nowadays be in sync, so that is not the issue. If
> >> they are not in sync, I'll never file a bug report.
> >
> > But the reader may not know that.
>
> To be honest, apart from you I think most readers aren't aware of it
> being possibly an issue.
Maybe not, in which case yoou could fold together those two rows.
> >>> some-dependency <version> <version>
> >>> binary package (currenlty in testing) (currently in unstable)
> >>>
> >>> other packages those from testing those from testing
> >>>
> >>> or something ?
> >
> > To put it another way, I think the existing prose representation is
> > trying to present and contrast a fairly complicated pair of
> > situations. A more structured representation can help.
>
> I'll be pondering on it a bit more. I am missing the information in the
> britney excuses to actually add the "some-dependencies" row, which makes
> the table less useful/correct if I leave that out. It would also mean I
> have to restructure my data file and tooling to add the current version
> in testing as I don't process that currently. I want to fix other issues
> first.
Then you could write something ambiguous in the table, maybe ?
deps involved in versions from versions from
same migration[1] Debian testing Debian unstable
with probably a footnote:
[1] [insert explanation of which packages that might be,
and/or how to find out what they were]
Explicitly presenting the missingness of information in this way is a
lot clearer than attempting to write prose which carefully omits to
specify it.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: