Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 25 octobre 2016 07:33 +0200, Tollef Fog Heen : >> * Specifically, failed to give clear and constructive directions to >>those willing to do the work; > > I disagree with those characterisations. He's asked for clarifications > on what is broken without anything resembling an adequate reply. Sorry? When did that happen? Do you refer to (IMO, the single occurrence where some clarifications were asked): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166 I replied: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171 I now understand that the answer was not enough, but this is new information. As of 2014, there was no answer to this message. The whole bug report is about people trying to understand and give information and the maintainer not giving a damn. People saying that gtags don't work at all for them didn't get any reply: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#34 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190 If you refer to what Ron is asking in #841294, this is far too late. I won't help to debug a 8+ years version of a software while the newest version works just fine for me. Would you? It is not like this version is somewhat maintained (as if it was a fork). The latest upload was in 2010. -- Make your program read from top to bottom. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
]] Ian Jackson > So in summary, the maintainer has: > > * Not packaged the new upstream version due to concerns about a >feature which is not present in the current Debian version and >which could therefore be removed from a new-upstream-version upload >without causing a regression in Debian; htags is in the version in Debian. > * Failed to engage positively with all of the many people who have >enquired about the question; > > * Specifically, failed to give clear and constructive directions to >those willing to do the work; I disagree with those characterisations. He's asked for clarifications on what is broken without anything resembling an adequate reply. I'm not going to comment further on your personal attacks against the maintainer. I think you're behaving below yourself and that you should stop. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
]] Wei Liu > On Tue, 25 Oct 2016 05:47:27 +1030 Ron wrote: > [...] > > That's basically why "just nuke htags now" is starting to look like > > a viable, and even sensible, option. But it's tricky to know who > > might be upset by that - and we don't have a clear idea of exactly > > what we'd really gain elsewhere from that tradeoff, since most of > > the people saying "I need a new upstream" haven't actually been > > telling us what the real problem is which that fixes, even when I > > asked. > > Gtags in Debian doesn't work with modern code base. Last time I tried (several > years ago), it segfault'ed while trying to index Linux kernel. FWIW, it worked fine in a test run I just did (on linux-4.9 rc 1), and last time I used it, it also worked fine with the emacs integration, so I don't recognise the crying from the rooftops about it being broken in Debian. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#841294: Overrule maintainer of "global" to package a new upstream version
So in summary, the maintainer has: * Not packaged the new upstream version due to concerns about a feature which is not present in the current Debian version and which could therefore be removed from a new-upstream-version upload without causing a regression in Debian; * Explicitly and repeatedly blocked other people who wanted to do the work to upload the new version (possibly with the troublesome feature removed); * Failed to engage positively with all of the many people who have enquired about the question; * Specifically, failed to give clear and constructive directions to those willing to do the work; The above have been carrying on for many many years. There has been no upload for six years. Most recently: * The maintainer has completely ignored a bug filed in March where sseveral people request an update and where it is obvious that no-one really understands the problem. It is not necessary to decide whether the CGI feature should be disabled, or should ideally be fixed. It is in fact not necessary to make any difficult technical analyses to conclude that the maintainer has made a massive net negative contribution to this package. They have done this solely by virtue of their position as the Debian maintainer. The maintainer has abused the maintainer's gatekeeper role. There are people ready and willing to do the work, who are currently blocked. Giving this package to a new maintainer is a no-brainer. If the TC will not depose a maintainer in circumstances like these, what will it take ? Please do not come to a "negotiated settlement" which leaves the current maintainer in charge. The effect of that is that all the constructive and useful people will be subject to the arbitrary whims of the the current maintainer. If the TC's decision, in such a clear case of abuse of power, is to leave the problem maintainer in charge, that is a decision to allow that person to continue to block people if they feel like it. With the TC's current attitude, it takes desperation (as well as determination and courage) to take a matter like this to the TC. If you have anything left to lose, taking this kind of dispute to the TC is a very risky step: the TC is not likely to get rid of a despot, and despots do not react well to challenges to their authority. So the petitioner (who probably cares about the package) is still under the maintainer's thumb, but they have annoyed the maintainer. Please would the TC prove me wrong. (For a change.) Ian. (quite frustrated) -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Tue, 25 Oct 2016 05:47:27 +1030 Ron wrote: [...] > That's basically why "just nuke htags now" is starting to look like > a viable, and even sensible, option. But it's tricky to know who > might be upset by that - and we don't have a clear idea of exactly > what we'd really gain elsewhere from that tradeoff, since most of > the people saying "I need a new upstream" haven't actually been > telling us what the real problem is which that fixes, even when I > asked. Gtags in Debian doesn't work with modern code base. Last time I tried (several years ago), it segfault'ed while trying to index Linux kernel. Here is my two cents on the issue of whether Debian should update global to a newer version and nuke htags: While I can't provide concrete numbers on how many people care or don't care about htags, there are some proxies that can help with this: 1. Most if not all the bug reporters for global package don't use htags. 2. Other distros' maintainers / users don't seem to care about htags or its implications. 3. The Debian users of global, according to popcon, is declining, which means less and less people care about current package (hence htags, for that matter). The core functionality of global is code indexing. As it stands, the current version is buggy and chokes on modern code base. The usability of the current package is only going to be less and less. No matter how secured the current package is, Debian users won't be able to use it because it can't generate index files in the first place. Eventually no-one will use this package. All in all, I think it is a disservice to Debian users to keep the status quo. I believe you've exhausted all venues to communicate with upstream your concern about CGI scripts. It is unfortunate that no progress was made in the last 8+ years. Under such circumstance, sacrificing a non-core functionality (htags) to serve the greater good seems to be a good trade-off to me. Wei.
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Oct 24, 2016 at 12:48:10PM -0500, Don Armstrong wrote: > On Sun, 23 Oct 2016, Tollef Fog Heen wrote: > > 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. > > It sure looks like upstream has removed the CGI generation option from > ctags itself, and no longer supports the --system-cgi option. Htags > appear to now just be generated statically, with the possibility of a > generated CGI as well [which seems to just set appropriate paths.] > > It's quite possible that I've totally missed something (the upstream > manual is a bit impenetrable), but maybe this will obviate the need to > answer this question? Only half-missed :) That removes any trace of the ability to generate a _static_ CGI that can be audited and installed to a system path. Which basically takes us back to the original situation from the 90's again, where the CGI is generated dynamically for each source repo, and is expected to be allowed to execute from the same tree as the static html content. It is possible to generate html that doesn't use a CGI at all, but that completely removes the ability to search the gtags database (which is what the CGI is needed to do) - which makes htags fairly useless, since the whole point of global is the tag search function, and you really would be far better off using something like doxygen instead which provides client side search functionality. The evolution was basically: - 1999 I added the ability to generate static CGI and use it securely. It was then suitable for use as a distro package, and uploaded to Debian. Upstream was sensitive about accepting major contributions that might mean he couldn't relicence it without permission from other authors, so he wanted the major parts of that kept separate, and we added only the hooks needed to support it to the main body of his code. (at some point after that he did change the licence from BSD to GPL). - 2010 Upstream proposed replacing that with a mechanism that was part of the 'upstream' code, and approached me privately to review his proposed changes. This was the "run a generated script as root and/or chmod 777 the privileged directory" option. He then wasn't interested in anything but a rubberstamp acceptance of that, and I couldn't convince him why that would be Troublesome. At that point he also deliberately removed the old interfaces that were necessary to support what we had, and the stalemate began. - At some point more recently, he broke that mechanism too, then dropped it completely (which is the change you were looking at). So now we're back to the pre-1999 option of only having it generated dynamically, hardcoded to be in the same tree as the static html. Which was already a fairly strongly condemned practice in the 90's. So basically, you've now got a choice of "Something worse than doxygen with no search functionality", or something that's a PITA to make work at best (you need to let your web server execute CGIs from arbitrary paths), and a security hole waiting for people to walk through at worst, and potentially still worse than what you'd get from doxygen anyway. I haven't audited the most recent code in detail yet, but the older code and docs used to be full of warnings along the lines of "if you put this on the public internet, you lose. Don't do that.". Which doesn't seem like something we really want in a distro package. That's basically why "just nuke htags now" is starting to look like a viable, and even sensible, option. But it's tricky to know who might be upset by that - and we don't have a clear idea of exactly what we'd really gain elsewhere from that tradeoff, since most of the people saying "I need a new upstream" haven't actually been telling us what the real problem is which that fixes, even when I asked. It's quite possible that some of those would just need a trivial patch to what we currently have - but with these latest changes to htags, I am feeling more and more like the writing is on the wall for its ultimate demise now - even if upstream isn't accepting that yet. But I haven't forgotten the hatemail I got for finally killing off svgatextmode, a whole decade after its upstream declared it an obsolete solution, when kms finally made it impossible to keep it working - so I don't underestimate what some people might cling to. Cheers, Ron
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, 24 Oct 2016, Vincent Bernat wrote: > ❦ 24 octobre 2016 12:48 -0500, Don Armstrong : > > > [Also, I'd like to note that currently Punit has not participated in > > the CTTE bug, and the last comment on #574947 was in 2014, so I'm not > > convinced that we have an alternative maintainer even if we were to > > decide to change ownership of this package.] > > There is also #816924. As for #574947, Ron stopped any participation. > I don't see what should be expected from other participants. Two of them > proposed an updated packaging, one of them proposed to help as a > co-maintainer, none of them got any attention. Ah, excellent; I missed #816924. I withdraw this criticism. -- Don Armstrong https://www.donarmstrong.com I'm sorry about those late night emails. I only said those things because I was too drunk to be afraid. -- a softer world #579 http://www.asofterworld.com/index.php?id=579
Bug#841294: Overrule maintainer of "global" to package a new upstream version
❦ 24 octobre 2016 12:48 -0500, Don Armstrong : > [Also, I'd like to note that currently Punit has not participated in > the CTTE bug, and the last comment on #574947 was in 2014, so I'm not > convinced that we have an alternative maintainer even if we were to > decide to change ownership of this package.] There is also #816924. As for #574947, Ron stopped any participation. I don't see what should be expected from other participants. Two of them proposed an updated packaging, one of them proposed to help as a co-maintainer, none of them got any attention. -- It has long been an axiom of mine that the little things are infinitely the most important. -- Sir Arthur Conan Doyle, "A Case of Identity" signature.asc Description: PGP signature
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Sun, 23 Oct 2016, Tollef Fog Heen wrote: > 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. It sure looks like upstream has removed the CGI generation option from ctags itself, and no longer supports the --system-cgi option. Htags appear to now just be generated statically, with the possibility of a generated CGI as well [which seems to just set appropriate paths.] It's quite possible that I've totally missed something (the upstream manual is a bit impenetrable), but maybe this will obviate the need to answer this question? [Also, I'd like to note that currently Punit has not participated in the CTTE bug, and the last comment on #574947 was in 2014, so I'm not convinced that we have an alternative maintainer even if we were to decide to change ownership of this package.] -- Don Armstrong https://www.donarmstrong.com If everything seems to be going well, you have obviously overlooked something. -- Steven Wright
Bug#841294: Overrule maintainer of "global" to package a new upstream version
On Mon, Oct 24, 2016 at 03:11:15PM +0100, Ian Jackson wrote:
> Tollef Fog Heen writes ("Bug#841294: Overrule maintainer of "global" to
> package a new upstream version"):
> > 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.
>
> I don't think the TC should be stepping in to make these kind of
> decisions about the package. Rather, the TC should give the package
> to the people who want to do the work and are currently blocked.
Let me see if I've got this straight ... You're saying that the TC
shouldn't "Make a decision when asked to do so", or "Offer advice" ...
And that it should do that by making a decision to ignore the facts
presented to it and instead summarily delegate that job to someone
who promised to do the work 2 years ago but hasn't, and someone who
has said quite plainly here that they aren't interested in doing
any work at all to understand the facts or detail their actual
problems to us accurately?
You should do irony for a living. This is pure gold.
> There is IMO no indication that the prospective new maintainers would
> do a bad job or that their strategy for dealing with this CGI problem
> (to wit, removing the feature) is inappropriate. The maintainer's
> comments about this are FUD. The level of demand for this feature
> would have to be very substantial for it to justify leaving this
> package at such an ancient version for years and years.
How is that any different from saying the level of demand for the
(still unspecified) new features that are needed to support something
which apparently has so little interest that it's not even packaged
for Debian would have to be "very substantial for it to justify breaking
an existing feature that we've distributed and supported for 17 years"?
This is a platitude you could have pulled from a fortune cookie. Not an
argument with any technical basis or insight or merit. And not the kind
of hollow nonsense we should apply in either direction for making a
decision about the best thing to do with this.
> Also, it is not right to reverse the burden of proof this way: the
> maintainer is suggesting that the feature could only be removed, to
> unblock a new upstream version, if it could somehow be proved that
> people don't need this feature. Well, we don't know how many people
> use this feature
Upstream asserts this is an important feature and that they will not
remove it. It's supported by doxygen. It was the outstanding feature
of this package in 1999 which got it packaged for Debian in the first
place.
So tell us again who is trying to "reverse the burden of proof" here?
I'll put a dollar down that says you don't even know what the features
of this software package were at all before you wrote that.
> but we do know that the package right now is in bad shape.
And we know that each new upstream release for the last few years
appears to put it in even worse shape in some respects.
You don't get out of a bad situation by pretending you aren't stuck
deep in the middle of one.
> The maintainer here has only engaged on this issue because the TC has
> become involved, despite extensive efforts by several contributors to
> unblock things. IMO explanations now are too late.
"extensive efforts". Is that what the cool kids call complaining
without even explaining or investigating what you are complaining
about these days?
I made the effort to detail the situation here in as much detail
as possible precisely so that people who are tasked by the project
to provide independent technical guidance can help us arrive at a
thoughtful consensus that's a bit broader than just me having to
repeatedly explain why things are like they are to people who don't
actually care as long as they get what they want, without having to
put any real effort or thought in, and without any regard to the
effect that might have on other users.
And so that if or when what we decide does upset someone else (which
is almost guaranteed as an outcome one way or another), we can point
those people to a considered consensus instead of having them level
ridiculous accusations at me, and appealing again to the TC to
override that decision too.
If we're going to do this here, we should do it once, and do it
right. It's never "too late" to want good decisions.
> Furthermore, the TC should make a decision rapidly so that a fixed
> version of the package can be in stretch.
So that if we do make a terrible mistake nobody will have time to
notice or get it fixed before it's locked in for an entire release
cycle?
I must say it was hard not to notice you seemed to be possessed by
a particular urgency with respect to this for some reason though ...
If we take the most charitable interpretation that is possible of your
initial response to this bug - a
Bug#841294: Overrule maintainer of "global" to package a new upstream version
Tollef Fog Heen writes ("Bug#841294: Overrule maintainer of "global" to package
a new upstream version"):
> [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».
Some years ago.
> 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.
I don't think the TC should be stepping in to make these kind of
decisions about the package. Rather, the TC should give the package
to the people who want to do the work and are currently blocked.
There is IMO no indication that the prospective new maintainers would
do a bad job or that their strategy for dealing with this CGI problem
(to wit, removing the feature) is inappropriate. The maintainer's
comments about this are FUD. The level of demand for this feature
would have to be very substantial for it to justify leaving this
package at such an ancient version for years and years. Also, it is
not right to reverse the burden of proof this way: the maintainer is
suggesting that the feature could only be removed, to unblock a new
upstream version, if it could somehow be proved that people don't need
this feature. Well, we don't know how many people use this feature
but we do know that the package right now is in bad shape.
The maintainer here has only engaged on this issue because the TC has
become involved, despite extensive efforts by several contributors to
unblock things. IMO explanations now are too late.
Furthermore, the TC should make a decision rapidly so that a fixed
version of the package can be in stretch.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
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
