Bug#841294: Overrule maitainer of "global" to package a new upstream version
Hi Sam,
On Wed, Nov 30, 2016 at 11:39:08AM -0500, Sam Hartman wrote:
> >>>>> "Ron" == Ron <ron@debian.org> writes:
>
> Ron> Hi OdyX,
>
> Ron> On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud wrote:
> >> Hi there,
> >>
> >> I've been mostly VAC, and only now found enough time to properly
> >> read through this bug log. In the interest of transparency and to
> >> help the TC reach a consensus (also through understanding what
> >> the other members' understanding, ideas and positions are), here
> >> comes my current understanding of the problem at hand.
> >>
> >> As preamble, I will upfront state that I have _not_ looked in the
> >> precise details of the so-called 'htags' functionality, as, the
> >> rest will show, my current viewpoint on the problem is that it
> >> doesn't matter.
>
> Ron> If we run with your proposal, what are you actually suggesting
> Ron> we tell the people who'd be upset by the loss of htags without
> Ron> notice in Stretch? Because I don't really see how you've
> Ron> addressed that here.
>
> Ron, thanks for working with the process.
Thanks for engaging with the question :)
I was a little disappointed that all OdyX had to say about it was:
<OdyX> I've sent a long mail with my opinion, and Ron's answer hasn't
altered my conviction yet.
Because "lalala, I'm not listening" isn't really an answer to a simple
direct question. And definitely not something that I can wrap with
"Sorry, but a group of Debian Developers considered this all in careful
detail, and this is what we have decided", when breaking the news to
affected people.
> I think that one thing you sometimes find when you try and build
> consensus is that your conception of the problem and even the values by
> which a solution should be judged is not shared.
I think you and I shared some opinions about the merits of the IETF
model for consensus on #-devel back when people were last exasperated
with Ian's antics and looking to get some new blood and new ways of
thinking into the ctte. So yes, I don't have a problem with my view
of things ending up being what's in the rough - the important part is
that the questions raised have been answered, and that there's rough
consensus those answers are sufficient to actually address the problem
in some manner.
Or more concisely:
"Rough consensus is achieved when all issues are addressed, but not
necessarily accommodated"
https://tools.ietf.org/html/rfc7282, if people aren't already familiar
with that process.
> As I understand it, you believe we should be evaluating the technical
> options and that preserving things that work is of high value.
>
> I think a lot of us believe that get newest code is a presumptive value
> especially over the multiple releases time frame.
It's probably a bit more subtle than that, though my context is certainly
going to be coloured by knowing the history of this particular package.
This is a package which required significant patching to bring it up to
what was considered acceptable practice for distro software from its very
first release with debian back in 1999. Some of the issues were just
general problems and bugs, and upstream took patches for those. And some
of them were things he just didn't care about (or understand) at all,
but he welcomed them being maintained separately as distro patches.
So I don't see it as an unusual thing for us to patch the problems that
are effecting distro users.
And I've looked at what the newer versions have added, and it's not like
there's a lot there which could really be described as earth shattering
must-haves.
And I don't think the only answer to fixing what Vincent is complaining
about, or the issues that Wookey looked into more recently is "new
upstream or bust". I'm pretty sure that we could probably fix those
relatively simply with patches to what we have now.
I even asked for enough information to be able to assess and/or do that.
But there was no interest in providing that from Vincent or Punit, and
no other user of ggtags has surfaced to put their hand up, so like most
things with insufficient information and interest, that went no further
so far.
So as a one sentence answer, "my belief" is probably more like "we can
have the best of both worlds for Stretch". If the people expending
energy arguing here, spent just a tiny portion of that on looking into
their *problem* instead of fighting over their line-of-least-work
solution.
I'm not insisting that's what we should do. But it's certainly an
option, and it dodges the bullet of having to say "Sucks to be you"
without any notice at all. And it doesn't take anything away from
the people who want "new upstream or bust" for Stretch, because it
can still be available to them in backports. Without going scorched
earth on the other users, who would have no other option but to
package their own local versions for the duration of Stretch.
> That is, I disagree with you that I need to address the question of
> htags and figure out whether htags users are being impacted.
> That might have been true for one release.
> But over a longer time frame, the really strong presumption is that we
> prefer a version that is being actively developed to one that isn't.
> That if people won't step forward and maintain htags, it goes awy.
There's clearly users of it recorded in the BTS, and historically it was
the thing that actually made this software interesting. Far more so than
just the tag search function (which lots of things do at least as well).
And I've already said here previously that personally, I think there are
now things which do what htags does better than htags too, so I'm not
irrationally attached to keeping it at all costs.
So I think we're actually in violent agreement here:
> That's a presumption. If someone gets evidence that htags is heavily
> used, we can consider that.
> We might even go so far given sufficient evidence to decide that forking
> global and never taking a new upstream was the right answer for our
> users. That would take a lot of evidence.
The only bit we apparently don't agree on yet, is the best way to test
what the evidence has to say.
I proposed we see who screams early in the Stretch+1 cycle, so that both
affected users and us had time to react if that was a mistake, and/or if
it provoked more people into actively fixing things that won't have
actually bitten them until we do that.
In the meantime, people wanting global6 not-negotiable, already have it
available, just in a different suite. And we can still fix real problems
in this version too if people provide real bug reports about them.
What you are suggesting is we burn our bridges in all suites, and if
that turns out to be a mistake, say "Oops. Too late to fix that for
Stretch now. Come back in a few years time (with patches?)."
But again, what I'm looking for here is a technically sound consensus.
That when people complain, I can refer them to with a straight face.
If I'm really in the rough on that, that's fine, I've never argued here
that it's "my way else we fight bitterly to the death over it".
I just don't want it to be embarrassingly dumb, having no better
justification than some dogma about the importance of version numbers
over all else.
"Sucks to be you, but my hands are tied because 6 > 5" isn't what I
imagine draws people to using Debian, or what we should expect from
diligent maintainers.
> I disagree with your approach that the people wanting to remove htags
> need to show that it is being used. I disagree with your view that over
> the timescales involved, people wanting a new upstream need to justify
> that.
>
> Yes, removing htags creates a regression.
>
> Yes, I'm effectively saying "If you're using htags, sucks to be you. If
> you're willing to spend effort maintaining a version of htags that is
> secure, then we might be able to bring it back.
I appreciate you acknowledging and taking ownership of that.
It has been frustrating to watch the argument ignoring it go from
the plainly false "nobody uses it" through the privileged "ok, maybe
people do use it, but they aren't as important as me and my friends".
I found this particularly boggling:
<OdyX> It seems everyon is assuming this 'htags' thing is un-patchable
by anyone. We're patching software on a routine basis in Debian...
Since it uses that argument to say "it's htags users' fault if they
didn't patch it" (when they are on the record for repeatedly trying
to do so upstream) - while at the same time insisting that the only
way to address other bugs for a few niche use cases is to _not_ patch
them, but instead bring in a new upstream warts and all (when those
people are on the record as saying they aren't interested in even
reporting their issues with sufficient detail to help us do that).
And then to express worry about "rewarding bad behaviour" ...
> Yes, it's possible that we'll learn we broke things and need to revert.
>
> But I think what you're getting here from a lot of people is a belief
> that our community norm strongly favors active development and new
> software. And sometimes when features are effectively not maintained in
> a manner that we can package them, they go away.
>
> I don't think it's reasonable to defer this to upstream and wait until
> upstream removes htags.
>
> I have tried to understand the technical issues. I'm not sure I'm 100%
> in agreement in your analysis there, but I'm fairly close. However, I
> haven't found the technical issues tend to affect my analysis of what
> Debian should do.
>
>
> I'd strongly urge you to work on a global6 package. I don't care
> whether it's called global or global6. I don't think it should include
> insecure cgi scripts that are enabled by default. I'd be fine if it
> didn't include htags at all.
> I'm not saying upload that package now; I'm not saying where to upload
> it.
> (Although I wouldn't object to an upload to experimental or unstable)
> I think having that package ready and keeping options open as long as
> possible would help preserve our ability to work through this process.
> I hope that would go a long way to addressing people's feelings of
> frustration.
I'm likewise primarily interested in seeing us arrive at a well
considered consensus about how to proceed.
I'm not particularly worried about whether I "win" any argument here
or not - my ideal is to see the concerns of all sides of this actually
be addressed in the best manner our collective wisdom is able.
In the best case, we'll have a good solution offering something real
for everyone.
In the not so ideal case, you give me a scapegoat to blame when people
scream about what a stupid thing we did.
In the worst case, the consensus is something I consider such an insane
waste of time for such a tiny number of users, that I'll hand it to
someone else to be their nightmare instead of mine. It's not like I
can't maintain my own private version if that's what I ultimately need
to do.
But either way, as long as it's a genuine rough consensus, that doesn't
simply ignore the hard questions, then I'll be happy to facilitate it,
whatever it is. I'm certainly not going to get EXTREMELY ANGRY about
it if things don't go "my way", and do something hostile or malicious
or stupid.
Understanding of the issues and constructive suggestions to address
them are _all_ I've ever asked for here. It saddens me that we still
have people who think the only way to solve things is to rally a bigger
lynch mob than the people who see things differently to what you do,
and try to get what you want by force and attrition and unfounded
rhetorical accusations.
That's not how collaborative projects work.
> Thanks for your consideration,
Likewise!
Ron
Reply to: