>>>>> "Ron" == Ron <r...@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