[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Sun, Oct 23, 2016 at 08:48:53PM +0200, Tollef Fog Heen wrote:
> ]] Ron 
> 
> > I'm appalled at the status quo.  My concern is that we don't make
> > that even worse with uninformed decisions.  In the absence of good
> > information, sometimes the best thing to do is be patient until
> > more of it arrives.
> 
> I agree with this.  On the other hand, waiting forever isn't productive
> either, which I think is where a lot of Vincent's frustration comes
> from, that it's hard to know when we've waited «long enough».

Indeed.  As I said in the initial summary I posted, I can certainly
sympathise with (and directly feel!) people's frustration with this,
it's my frustration too.  And my frustration with this is the same
sort of problem the TC has with any decision that isn't a clear cut
win-win - it doesn't really fix things to just move that frustration
to a different group of users.  It just restarts the debate with a
different group of angry players feeling hard done by, sending you
hate mail, and resorting to 'hostile' methods they hope might play
out in their favour.

So mostly for me, it had got to a point where I'd exhausted exploring
and advocating for all the obviously possible good outs - and after that
it wasn't so much a case of waiting 'long enough', but rather waiting
until something material changed which tipped the balance or reopened
the discussion with some new aspect to consider, which might make
something else actually look better overall than the status quo did.

... and it may well be that this has actually happened now with
upstream's decision to drop all support for providing a secure
system CGI of any form that people can use for this.  The upstream
code is basically now back to what it was in the 90's, with the only
way to use this being to allow execution of a generated CGI in the
same tree as the html content.  Which was already well known to be a
dangerous and ill advised idiom even back then ...


> I'm leaning towards dropping htags, since that seems to have problems
> security-wise (the idea of generated CGIs don't fill me with joy, at
> least, and hopefully not many others either), and also has a lot less
> value today than it used to back in the days.

That's the direction I'm tipping toward too.  At the very least, this
new change makes it even less desirable than it already was to ship
the new upstream version 'as is', so in the absence of other workable
suggestions, the salient question in my mind is basically boiling down
into:

 Do we just give up on htags as being a viable thing at all, drop it,
 and just worry about whether the rest of what global provides is
 actually sane enough to still ship?

 Or do we keep the current version of htags for existing users, and
 patch the things people report they are having problems with in
 the other parts?

The latter is mainly still an open question, because looking at the
new options global's gtags has added, none of them seem to be
particularly earth shattering innovations - though we still don't
actually have any answer on what is broken about the external ggtags
wrapper to know whether the new options are even related to that at
all.

So fixing that might not actually be all that hard if someone who
cares about the external tools which I don't use wants to look at
what is really broken about them, and might be the closest we get
to actually giving both sides of that something resembling a fair
compromise.  I'd certainly be prepared to review and apply any
sane patches to do that (and that's always been an open offer).

But it would still leave us with the abstract math question of
whether two half-sucks are greater or less than a whole.


And I don't know offhand whether there are any other external tools
we need to consider.  Vincent claimed there were "many frontends"
effected by this, but I don't know if that was a Rhetorical Many,
or based on a numbering system that goes {0,Many,ManyMany,...}, or
if he knows something else that he didn't detail - but nobody has
yet mentioned any other "frontends" in reports to the BTS or to me.
So if they actually exist, and do have problems, it would be good
to know what they are so we can include them in any assessment of
this too.


> Maybe the question we should ask is less «who/how many people use
> htags?» and more «what value does htags provide?».  I'm no big fan of
> arbitrarily breaking people's workflows, which we might be the result if
> we remove htags.

Yes, at the very least I think that's looking like the only metric
which we can objectively weigh up and base any decision along these
lines and its rationale upon.  I don't think we can entirely discount
existing users, but it's not looking like we're going to get any
stronger basis for a head count argument (for either side of this)
than we'd get from chicken entrails.

If we can at least tell them something like "We're really sorry,
but it's 2017, have you ever looked at doxygen?  Here's a handy
comparison." - that's a bit better than telling them "sorry, you
lost a nagging match that you didn't know was happening because
we hadn't broken things for you".  And at least gives them some
better basis for a counter argument (and for us to refute it)
than "you lost an arbitrary vote".


If we look at what we do actually know about the headcount argument,
it's really "not a lot".  Of the spectrum of people who gave input
to the BTS, there's one report which stands head and shoulders above
the rest, and should be a widely promoted poster child for how to
file a "new upstream" report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190

He tells us exactly what problem he was having, what he tested,
shows that he has a good understanding of the blocker, and that
indeed he'd be ok with us dropping htags if that's what we need
to do.  Full Marks, A++ for contributing useful information.

After that, the handwaving quotient increases rapidly and everything
gets more blurry.  Overall, we have maybe 2 people who definitively
say they don't use htags in what they posted to the BTS.  We can
call that 3 if we include Vincent, who seems to have affirmed that
in responses here but from what he said in the BTS it wasn't clear
if he really understood what "remove the CGI bit" actually meant.
And maybe call it 4 if we include what Wookey posted here ...
though reading what he said again, I'm not actually sure whether he
does really use any of this at all, or if he was just posting in
general support of having the TC help consider the question ...
(he was the only one who emailed me to ask if I knew about that
yet, and had never chimed in on the BTS threads, so it only just
occurred to me that might be what his real interest actually was.
Either way that doesn't change much though).

On the flip side, we have the guy who escalated the original bug
severity to Important.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#34
It's impossible to say exactly what his problem and desire was,
but unless he's using the word 'browse' very loosely, that would
seem to imply his interest might be in the output of htags - even
if the problem which made it 'unusable' to him was somewhere else
(since htags uses the indexes generated by gtags to be useful,
which is why the CGI is needed).

With a few exceptions, the rest of the me-too's all mostly range
from entirely contentless to 'effectively so', and none of them
tell us anything about whether or not they care about htags.
And even if all of them didn't, it would still be a tiny-tiny
portion of even the popcon count of users who haven't openly
complained (yet!) either way about the current state.

So if nobody can back up the "nobody uses it" argument with
something more concrete than that - I think that's about as far
as that one can usefully take us in any direction.  Which is to
say, basically nowhere at all.  We could have about as much
confidence in tossing a coin.


By contrast, the question of whether htags has in fact outlived
its useful shelf life is one that people here can objectively
assess and form an informed opinion about.  And put a statement
on the record about, as being the (a?) basis for whatever we
reach consensus to do.

I already gave my opinion on that in my initial summary here,
but if my opinion alone was enough to settle this for everyone,
then we wouldn't be here in the first place either, so it would
be helpful to have some other balanced and independent assessments
of that to back this up (or not) as an informed consensus best
option.

Many years ago, htags was a best of breed tool.  It even was the
main reason I first packaged this - since any editor worth its
salt (both the tool and the person) can do most of what gtags does
without the overhead of continually regenerating a tags file, but
a searchable hyperlinked representation of the source was really
useful back when we all had shitty tiny screens.

These days, I think it's hard to beat doxygen for that, and I don't
think upstream is doing it any favours by making it harder to use it
safely, and easily, and securely - but I can't rule out that other
people might still think differently, or have old habits dying hard,
or see something important in it that they don't get from doxygen.

So I do think that with my maintainer hat on, I could be swayed
by good evidence in either direction as to whether we should just
patch the warts in gtags where someone's use case needs that, or
just kill htags and let the hard core gtags users have New Shiny.

  Sway me :)
  Ron


Reply to: