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

Re: What to do when DD considers policy to be optional? [kubernetes]

Hello Dmitry, Janos, others,

On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote:

> Something interesting just happened. An inexperienced DD adopted a very
> complicated package (kubernetes) and uploaded it with changes that would have
> never been accepted by ftp-masters.

Specifically, as README.Debian states, the vendor/ subdirectory of the
source package contains more than two hundred Go libraries.

I can't speak for the whole FTP Team here, but if this had ended up in
NEW and I had been the FTP Team member to review it, I would indeed have
rejected it, on the grounds that accepting the upload renders Debian
less maintaintable in various ways.

> What would be best to do in such situation?

I think that I would start by filing an RC bug.

> The problem is not with DD's qualification (although this certainly plays a
> role) but with intentional non-compliance with policies and packaging
> practices.
> As a person who originally introduced Kubernetes to Debian I can say that it
> is indeed a lot of work to maintain this package and to reuse packaged
> libraries. But I've demonstrated that it is possible at least to some extent.
> New maintainer of kubernetes do not even make an attempt to build it properly
> and blatantly states the following in README which demonstrates profound lack
> of understanding of problems that were impairing maintenance of the package:
>    "I kindly ask purist aspirations that effectively halted Kubernetes'
>     release and updates in Debian for YEARS to be kept at bay."

The new maintainer presumably thinks that Policy should have an
exception for this sort of case -- let's assume good faith.

> I don't consider myself to be a purist. I have pragmatic approach to
> packaging but I feel concerned when policies and packaging practices are
> circumvented.
> I don't recall a situation when policing of how a package is maintained would
> be necessary long after package is accepted...
> What do we do to ensure quality work in situation of technological hijack
> when maintainer is unwilling to follow the practice or comply with policy?
> This is not a technical disagreement so I think that involving technical
> committee may not be the right way to handle the problem... Or is it?

I think it counts as a technical disagreement but surely there is room
for discussion in a bug report before involving the T.C.

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply to: