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 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." 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? -- Cheers, 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
Description: This is a digitally signed message part.