Re: Scikit-learn: Move to Debian Science?
Yaroslav Halchenko <yoh@debian.org> writes:
> On Tue, 05 Dec 2017, Ole Streicher wrote:
>> can we move scikit-learn to Debian Science as well please? This is
>> another package currently maintained by NeuroDebian, but in a bad state
>> since months. Since it is used in general science, it would be good if
>> that could be fixed by Debian Science maintainers (specifically, I will
>> have a look) as a team upload and direct commit to the repository.
>
> "Bad state" was a single failing unittest on exotic platforms AFAIK --
> or am I missing something?
"Bad state" means that there were two old RC bug not closed, which
caused the package to be either removed from testing, and/or (don't
remember) not migrating. And a new FTBFS which just showed up in the
build.
> That test could have been dealt efficiently via NMU, but noone did.
No, this is not so simple. As a stranger to the package, I have no idea
whether the problem is an important problem (which just does not show in
this particular case on x86), if it shows that the package is unusable
on these platforms of if it is just a minor glitch. That needs some
communication with upstream, which I ususally do not do, unless I am the
maintainer or at least a member of the maintaining team. And since in
that case the FTBFS appeared with the upload, I would usually think that
taking care is part of the after-upload procedure of the uploaded.
> Anyways -- I've uploaded a fixed up package to the archive earlier
> today. Let's see how it goes.
Great. Thanks.
> Although in general I do not mind moving packages under Debian Science,
> I do not see it as a panacea... quite often in my case it leads to me
> spending more time working around adjusting my workflow and to provide
> backports which we do for NeuroDebian. So unless I see that there is an
> immediate benefit overweighting the cons in this case, I would
> prefer to keep it as is for now. Sorry
I have no problem with that as long as the packages work well. I still
see for me personally that my threshold for doing an NMU is much higher
than for a team upload. Especially when I don't have commit access to
the repository.
My feeling is, however, that you weight the Debian package state lower
than the NeuroDebian workflow, since you call the problems as just "on
exotic platforms" (which anyway makes them not migrating, but collecting
RC bugs). This makes it difficult to maintain dependent packages.
Best regards
Ole
Reply to: