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

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.


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: