Re: What to do when DD considers policy to be optional? [kubernetes]
On Mon, 23 Mar 2020 18:47:18 -0700
Sean Whitton <spwhitton@spwhitton.name> wrote:
> Hello Dmitry, Janos, others,
>
> On Mon 23 Mar 2020 at 05:32PM +11, Dmitry Smirnov wrote:
>
> > What would be best to do in such situation?
>
> [...]
>
> I think that I would start by filing an RC bug.
+1
If you run into issues, then you'll want to contact the ftp-masters team.
It would be helpful if the bug mentioned the two solutions I'm aware of:
- Revert the offending changes
- Migrate from main to non-free
The latter would be much easier, but would destroy all the work you put in. :(
> > [...]
> > 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.
As a person who temporarily introduced gitea into Debian, I fully understand.
Unfortunately, I've found that such problems are often a result of poorly
written code where the approach tends to be, "I don't know how to do this
thing, so I'll copy a module that does this and 200 other things just as
poorly." </rant>
The lesson I learned was-
Just because something /can/ be packaged, does not mean it /should/ be packaged.
(pabs warned me about this hundreds of hours prior to me giving up)
> > I don't recall a situation when policing of how a package is maintained would
> > be necessary long after package is accepted...
It's rare, but it happens. My most recent experience was with bitlbee.
Unfortunately, our current auto-reject system is quite limited. Catching things
like this automatically is (currently) not possible and Debian relies of folks
like you. (btw- thanks for this report)
> > 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?
TC is not needed. This is a clear policy violation that the new maintainer
appears to have known about, even before the upload.
It concerns me that they thought this package warranted an exception...
--
Michael Lustfield
Reply to: