Final thoughts/votes on Kubuntu Policy

[Harald Sitter]

On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote:
>> On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman <ubuntu at kitterman.com>
> wrote:
>> > On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote:
>> >> On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman <ubuntu at kitterman.com>
>> >
>> > wrote:
>> >> > I, for one,
>> >> > think the notion that we won't apply known fixes because upstream is
>> >> > non-
>> >> > responsive is silly.  I don't intend to be bound by it.
>> >>
>> >> Where does the fix come from then?
>> >
>> > Could be defective Python code I figured out by myself (for reference,
>> > this
>> > exact scenario is why we had an even sort of working displayconfig in
>> > hardy - if this policy had been in effect, it would have had to be
>> > removed and not replaced since there was no replacement available).
>>
>> so why did you not pick up maintainership?
>
> Because it would have needed a full rewrite to work with the then brand new X
> stack reliably.  We were going to have a new tool for Intrepid anyway, so
> beating it into sort of working was enough for Kubuntu and I'm certainly not
> qualified to take on upstream development for all of KDE.

Why would you not be qualified? You created a Kubuntu specific fork of
the software, so since you were fit to maintain that one I am sure the
same would have worked upstream. Seeing as you were able to beat it
into working state for Kubuntu it would appear to me that there is
nothing that would have prevented you from doing the change upstream
and releasing a new tarball. At worse you had to roll a tarball
instead of dumping a patch into debian/ (which would then have had
up-to-date translations thus possibly not being all that much of a
waste of time to begin with), at best 3 other distributions had picked
it up and thanks to that ended up with a working display config in
their LTS release.

The reasons why we don't want to condone dead upstream pseudo
maintenance patchy nonesense is multifaceted. The fact that distro
patchy is selfish towards everyone else is one part of it. Another one
is that the patch policy needs a responsible person up the stream to
review and approve and possibly merge a patch, with out one the patch
policy doesn't allow certain patches at all.
Another important side of the argument is that of reliable and
balanced quality. No one takes on responsibility for the quality, so
we must assume it has excessively shitty quality or is of no use
because otherwise someone were to feel the need to stand up and take
on maintenance or at the very least care enough to fix startup
crashes, data loss, bug triage etc.etc.. And ultimately that leads to
the question of whether we should have a piece of software of
obviously shitty quality under our wings to begin with considering no
one else wants to care about it either.

All that being said, perhaps the policy ought to be amended to say
that instead of having the package removed from the archive it must
not be on our ISOs and Kubuntu should not be the maintainer. At the
end of the day what someone does because they want to is their own
business. So, if someone feels like foobar should be in the archive
and that they feel up to the task of keeping it not broken that's
their choice to make and execute. Even if it then reflects badly on
Kubuntu and Ubuntu at large if a user installs that software and finds
it to be unusable for whatever reason. There is not much one can do
about that, and this is a global problem to some extent anyway.

But, we as creators of Kubuntu however should not support selfish
life-support patching for the software we use to build our product on.
It does not benefit anyone to drag along broken unreliable software.
Giving it the boot on the other hand does not only free up resources
better spent elsewhere, it also makes people moan and whine about this
super important application that is now gone and this makes it all the
more likely that someone steps up and does what needs to be done to
make it a super awesome piece of software again.

The present policy is already given a lot of leeway to make sure the
user doesn't need to suffer unless there really is no other way. But
the must-not-be-patched thing is really not something that can be
changed or removed IMO. If patching maintained software is
semi-forking then patching unmaintained software that is entirely
broken as per the presented check list is a definite fork because the
patched version is then the only working version and thus the defacto
source to be used.

So, your concern is that this sort of short term workaround isn't
possible with the presented policy, but really it is. Instead of
making a distro patch you would commit your bandaid solution upstream,
release a new tarball. By doing that you are making your work easily
available to others and improve the quality of the upstream product.
You'd then be a maintainer (of sorts). Other distros as well as our
guys might have additional tweaks so they run it by you (for example
as per our patch policy) and maybe after 3 months you roll a new
tarball and official declare displayconfig is now to be considered
rubbishware and one should use xyreplacement going forward.
Instead of making other distros run circles around kubuntu packaging
to find the relevant patch and then somehow try to keep an eye on it
in case some other kubuntu dev improves on it, the very same thing has
been published upstream and everyone knows how and has tech to watch
upstream for cahnges and how to deal with upstream and even how to
roll a simple tarball from upstream including translations and whatnot
(e.g. the releaseme framework).

There does not appear to be anything wrong with sharing one's accomplishments.

HS