Bug#841294: Overrule maitainer of "global" to package a new upstream version

[Sam Hartman <hartmans@mit.edu>]

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

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.

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.

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.

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.

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.

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.

Thanks for your consideration,

--Sam