Re: python-cyvcf2 test failures (Was: python-pybedtools: fixing the failing tests)
On Sat, Jul 28, 2018 at 12:50:22AM +0200, Steffen Möller wrote:
> > I do not think that anybody of us is observing "random" README.source
> > files regularly. I'd consider a bug of severity minor the more
> > realistic approach that somebody might stumble upon the issue and will
> > try to fix it.
>
> Yes. Good point. The same problem we have with all those packages that
> we tolerate in salsa that never made it to our project servers. While adding
> all those RRIDs I was tempted a few times to complete a packaging effort
> and after a while found out why the packaging came to that halt. Grrr.
Documenting show stoppers in README.source is a good idea and we can not
really file bugs against non-existing packages. If there is an ITP bug
the BTS might be another option but I personally would inspect a
README.source for not yet released packages.
> The README.source is the right place, but how about putting a comment
> into the changelog file whenever README.source changes? I like that.
Sure. Why not. Changelog is invented to record changes.
BTW, if I intend to create real attention for other team members I add
a line
TODO: do_this_or_that
in d/changelog.
> If
> there are positive vibes towards that extra verbosity then let us try this
> for a while and then propose this for our Debian policy.
There is no point to add redundant things like "record changes in
d/changelog" to policy (may be I have misunderstood you?)
> I have it (still locally) now in the changelog, in copyright (where I
> commented out the
> Files-Excluded: htslib) and in README.source.
Remember to file a bug about this and please also give some details what
package might break when switching to htslib 1.9.
> >> It is a bit annoying but that there are these version incompatibilities.
> >> We cannot just go and substitute the 1.7 version.
> > As far as I know it was just python-pysam which was not updated to 1.8.
> Ah, ok. Seems like I forgot.
> > I have not yet checked recently whether this is the case. This is
> > another cry for more contribution. We **really** need more people doing
> > regular maintenance and check what package needs an upgrade.
> I am not exactly sure what kind of work that is which we need. When
> packages are well maintained, like cyvcf2 now, it needs someone to
> detect issues and communicate them. The detection is automated. The
> communication takes time.
Sure if we have tests the detection is automated. I just want to
stress that we really *should* communicate those issues as soon as
we spot these (and add the issues we opened to the according place
like README.source or the according bug in BTS).
> For non-maintained software that does not find a new maintainer the only
> answer I have a request for removal. With the advent of
> Docker/Singularity together with snapshot.d.o this is not too bad.
>
> What we need is some kind of reward structure. This does not need to be
> money, the one or other newspaper article about a young mother's cancer
> being cured after identifying the right T cell receptors with the help
> of Debian's packages would be enough for me. But that is me. Part of why
> I am so much after completing workflows is that this shifts our
> distribution from a package-level to a purpose-level. And if we do not
> find more hands for those purposes then, well, maybe we should package
> less and help using those packages more.
> > Do you know any specific package which does not work with version 1.9?
>
> No, not yet. We are at the very front of everything here. That 1.9
> release is just 9 days old or so.
OK.
> > Kind regards from DebConf 18
>
> Enjoy!
Thanks, I'll do
Andreas.
--
http://fam-tille.de
Reply to: