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
Attachment:
signature.asc
Description: This is a digitally signed message part.