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

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

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.

What would be best to do in such situation?

The problem is not with DD's qualification (although this certainly plays a 
role) but with intentional non-compliance with policies and packaging 

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."

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 

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?

 Dmitry Smirnov.


We do our friends no favors by pretending not to notice flaws in their
work, especially when those who are not their friends are bound to notice
these same flaws.
        -- Sam Harris

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: