On Mon, 23 Mar 2020 18:47:18 -0700 Sean Whitton <spwhit...@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
