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

[Uoti Urpala]

On Sat, 10 Dec 2016 06:54:17 +1030 Ron  wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contributed anything to either).  I'm afraid that's not
> how encouraging volunteers to contribute their time for you works ...
> sorry if this is news to you.

It was perfectly reasonable to ask that if you have any pretense at all
of actually doing the work expected of your maintainer position, you'd
contribute to creating packaging for the new upstream version, instead
of only attacking the people working on it.


> things.  But because the increasingly ill-named technical committee has once
> again refused to stick its collective necks out to actually offer technical
> advice when explicitly asked to.  We chopped some heads off the hydra, but

> Explaining things in careful detail has had every appearance of being a
> complete waste of my time whichever way this might have ended up.  The only

The fundamental problem with most of your technical arguments was that
they were arguments about upstream development, not about packaging.
Even if they were 100% true, they still would not justify how you have
handled the Debian package. If you disagree with upstream that way, you
should try to convince them, and if that fails and you care enough,
create a new upstream fork.

Instead, you turned the Debian packaging into a practical fork. That's
not the right place for hosting a new fork. You also obviously did a
bad job of maintaining your fork (given the complete lack of
development). Your attitude seems to have been that you insist on
keeping the original GLOBAL out of Debian, do no development at all
yourself, and if anyone has problems with your fork you insist that
they do the work of developing it. That's not reasonable at all.

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

[Punit Agrawal]

I just noticed I missed out responding to one of your queries in my reply.

On Wed, Nov 30, 2016 at 7:19 PM, Punit Agrawal  wrote:
> On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson
>  wrote:
>> Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to 
>> package a new upstream version"):
>>> In offline discussions with Wookey, we came to the realisation that
>>> reading the various bug reports (including this one) it is not very
>>> clear how global (upstream) is structured, the functionality it
>>> provides and bits that are holding back the debian update.
>>
>> Thank you for your clear and excellent explanation.
>>
>>
>> On to some questions it raises for me:
>>
>>> Optionally, "htags" can generate a dynamic index (which reduces disk
>>> space usage) but requires an http server setup to be able to serve the
>>> pages. In this scenario, you will also need to be able to execute CGI
>>> scripts as the symbol lookup is done when serving the http request (as
>>> opposed to pre-processed when using static pages).
>>>
>>> And this last bit (integration with system web server) is the
>>> functionality that had security concerns raised by Ron [etc.]
>>
>> So, to be clear, it is this functionality which is dropped in the
>> package that you and Wookey uploaded to experimental/delayed ?
>>
>
> The debian packaging added two tools not present in upstream -
> htconfig and htmake. These tools and debian patched htags together
> make the integration with system web server work to the extent that
> Ron was comfortable shipping the package. Both htmake and htconfig are
> authored by Ron.
>
> So although the package uploaded by Wookey retain the tools they have
> become non-functional due to upstream changes to htags. But as you
> point out, you can still achieve a very similar end result using other
> mechanisms.
>
>> But AIUI this functionality remains:
>>
>>> In addition to the above mechanisms, upstream also provides "htags"
>>> which can be used to generate an HTML version of the index. "htags"
>>> uses the index created by "gtags" and the source tree as input and
>>> generates html files which allow you to navigate the source code in
>>> the browser. By default, htags generates static pages which means you
>>> can browse the code in a local browser without requiring a web server.
>>
>>
>>
>> So the impact for a user of the existing functionality the regression
>> is not that their entire workflow is disrupted.
>
> That is exactly what I was trying to get across in my previous email.
>
>>
>> Rather (unless the software is improved) they have these choices:
>>
>>  - Put up with pregenerated html indices.  Is the only downside
>>of this that they use additional disk space, and presumably
>>cpu time to generate them ?

AFAICT, yes.

>>
>>  - Run the htags server on a high-numbered port somehow.  (Is there
>>some kind of simple scriptery provided, to do this?)
>
> It would be a web server - htags isn't a server in itself. Upstream's
> suggestion of using
>
> python -m CGIHTTPServer
>
> in the generated HTML folder worked for the package Wookey has
> uploaded. This command can be executed with user privileges and runs a
> local instance of an http server.
>
> IIUC, running the web server with user privileges, prevents it from
> binding to external interfaces/IP addresses.
>
>>
>>  - If the machine is not really multi-user, tear down the security
>>boundary defending the webserver from their user account, and give
>>their user account access to the webserver cgi directory (or plumb
>>it in with symlinks).  (Are there any instructions or scripts for
>>this?)  (Also this assumes that the source code is not super
>>secret.)
>
> So I am not very familiar with cgi scripts (having never used it
> myself) but I believe what you say is possible - somebody with a
> little more knowledge than me should be easily able to come up with
> the instructions.
>
>>
>> I don't know much about this, but several of these choices seem likely
>> to be plausible choices for many if not most current users of htags.
>>
>>
>> FAOD none of this changes my view about the proper resolution of this
>> TC petition.  But answers might help clarify the discussion.
>>
>> Thanks,
>> Ian.
>>
>> --
>> Ian Jackson    These 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

[Punit Agrawal]

On Wed, Nov 30, 2016 at 4:56 PM, Ian Jackson
 wrote:
> Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package 
> a new upstream version"):
>> In offline discussions with Wookey, we came to the realisation that
>> reading the various bug reports (including this one) it is not very
>> clear how global (upstream) is structured, the functionality it
>> provides and bits that are holding back the debian update.
>
> Thank you for your clear and excellent explanation.
>
>
> On to some questions it raises for me:
>
>> Optionally, "htags" can generate a dynamic index (which reduces disk
>> space usage) but requires an http server setup to be able to serve the
>> pages. In this scenario, you will also need to be able to execute CGI
>> scripts as the symbol lookup is done when serving the http request (as
>> opposed to pre-processed when using static pages).
>>
>> And this last bit (integration with system web server) is the
>> functionality that had security concerns raised by Ron [etc.]
>
> So, to be clear, it is this functionality which is dropped in the
> package that you and Wookey uploaded to experimental/delayed ?
>

The debian packaging added two tools not present in upstream -
htconfig and htmake. These tools and debian patched htags together
make the integration with system web server work to the extent that
Ron was comfortable shipping the package. Both htmake and htconfig are
authored by Ron.

So although the package uploaded by Wookey retain the tools they have
become non-functional due to upstream changes to htags. But as you
point out, you can still achieve a very similar end result using other
mechanisms.

> But AIUI this functionality remains:
>
>> In addition to the above mechanisms, upstream also provides "htags"
>> which can be used to generate an HTML version of the index. "htags"
>> uses the index created by "gtags" and the source tree as input and
>> generates html files which allow you to navigate the source code in
>> the browser. By default, htags generates static pages which means you
>> can browse the code in a local browser without requiring a web server.
>
>
>
> So the impact for a user of the existing functionality the regression
> is not that their entire workflow is disrupted.

That is exactly what I was trying to get across in my previous email.

>
> Rather (unless the software is improved) they have these choices:
>
>  - Put up with pregenerated html indices.  Is the only downside
>of this that they use additional disk space, and presumably
>cpu time to generate them ?

There

>
>  - Run the htags server on a high-numbered port somehow.  (Is there
>some kind of simple scriptery provided, to do this?)

It would be a web server - htags isn't a server in itself. Upstream's
suggestion of using

python -m CGIHTTPServer

in the generated HTML folder worked for the package Wookey has
uploaded. This command can be executed with user privileges and runs a
local instance of an http server.

IIUC, running the web server with user privileges, prevents it from
binding to external interfaces/IP addresses.

>
>  - If the machine is not really multi-user, tear down the security
>boundary defending the webserver from their user account, and give
>their user account access to the webserver cgi directory (or plumb
>it in with symlinks).  (Are there any instructions or scripts for
>this?)  (Also this assumes that the source code is not super
>secret.)

So I am not very familiar with cgi scripts (having never used it
myself) but I believe what you say is possible - somebody with a
little more knowledge than me should be easily able to come up with
the instructions.

>
> I don't know much about this, but several of these choices seem likely
> to be plausible choices for many if not most current users of htags.
>
>
> FAOD none of this changes my view about the proper resolution of this
> TC petition.  But answers might help clarify the discussion.
>
> Thanks,
> Ian.
>
> --
> Ian Jackson    These 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

[Ian Jackson]

Punit Agrawal writes ("Bug#841294: Overrule maintainer of "global" to package a 
new upstream version"):
> In offline discussions with Wookey, we came to the realisation that
> reading the various bug reports (including this one) it is not very
> clear how global (upstream) is structured, the functionality it
> provides and bits that are holding back the debian update.

Thank you for your clear and excellent explanation.


On to some questions it raises for me:

> Optionally, "htags" can generate a dynamic index (which reduces disk
> space usage) but requires an http server setup to be able to serve the
> pages. In this scenario, you will also need to be able to execute CGI
> scripts as the symbol lookup is done when serving the http request (as
> opposed to pre-processed when using static pages).
> 
> And this last bit (integration with system web server) is the
> functionality that had security concerns raised by Ron [etc.]

So, to be clear, it is this functionality which is dropped in the
package that you and Wookey uploaded to experimental/delayed ?

But AIUI this functionality remains:

> In addition to the above mechanisms, upstream also provides "htags"
> which can be used to generate an HTML version of the index. "htags"
> uses the index created by "gtags" and the source tree as input and
> generates html files which allow you to navigate the source code in
> the browser. By default, htags generates static pages which means you
> can browse the code in a local browser without requiring a web server.



So the impact for a user of the existing functionality the regression
is not that their entire workflow is disrupted.

Rather (unless the software is improved) they have these choices:

 - Put up with pregenerated html indices.  Is the only downside
   of this that they use additional disk space, and presumably
   cpu time to generate them ?

 - Run the htags server on a high-numbered port somehow.  (Is there
   some kind of simple scriptery provided, to do this?)

 - If the machine is not really multi-user, tear down the security
   boundary defending the webserver from their user account, and give
   their user account access to the webserver cgi directory (or plumb
   it in with symlinks).  (Are there any instructions or scripts for
   this?)  (Also this assumes that the source code is not super
   secret.)

I don't know much about this, but several of these choices seem likely
to be plausible choices for many if not most current users of htags.


FAOD none of this changes my view about the proper resolution of this
TC petition.  But answers might help clarify the discussion.

Thanks,
Ian.

-- 
Ian Jackson    These 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

[Punit Agrawal]

On Wed, Nov 23, 2016 at 5:19 PM, Didier 'OdyX' Raboud  wrote:
> The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up
> the different outcome possibilities, which would help forming our opinions.
> Not all these options are exclusive, or would need an actual TC decision.
>
> Here we go:
>
> A) 'global' stays maintained as it currently is.
>
> This would imply:
>  - no new 'global' upstream release before stretch,
>  - no 'htags removal' warning in stretch,
>  - possibility for the maintainer (and/or other interested parties) to start
>maintaining a 'global6'; this wouldn't offer any guarantee for a more
>recent version of 'global' in stretch. This would also imply having two
>'global' packages in certain suites.
>
> B) A fresher version of 'global' is uploaded to experimental 'soon'
>(with or without interested parties' help; with or without a TC decision)
>
> This would imply:
>  - any interested party would file (and close) Debian bugs for issues and
>regressions (with appropriate severities), to make the 'fitness for a
>stable release' assessment easier, and earlier.
>
> C) After the release of stretch, a fresher version of 'global' is uploaded to
>unstable with the explicit goal of making it available in buster.
>
> This would imply:
>  - any interested party would file (and close) Debian bugs for issues and
>regressions (with appropriate severities), to make the 'fitness for a
>stable release' assessment easier.
>  - after migration to testing, this would make the fresher version of 'global'
>available for backporting to stretch-backports.
>  - the version of 'global' released in stretch could carry 'htags removal'
>warnings;
>
> D) A fresher version of 'global' is uploaded to unstable 'soon', targetting
>stretch (with or without interested parties' help; with or without a TC
>decision)
>
> This would imply:
>  - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
>in a TC vote);
>  - any interested party (including the maintainer) would file (and close)
>Debian bugs for issues and regressions (with appropriate severities), to
>make the 'fitness for a stable release' assessment easier.
>  - that this fresher version of 'global' would reach 'fit for release' status
>before the Stretch release.
>
> E) the 'global' package is handed to other maintainer(s)
>
> This would imply:
>  - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
>in the TC vote);

In offline discussions with Wookey, we came to the realisation that
reading the various bug reports (including this one) it is not very
clear how global (upstream) is structured, the functionality it
provides and bits that are holding back the debian update.

Gnu Global is a source code tagging system similar in functionality to
ctags or cscope. It allows searching for symbol definitions and use in
the codebase by splitting the functionality into two steps -

* Indexing - This is a offline step where an index of source code
symbols definitions and references for a code base is created. This
functionality is provided by "gtags" binary (part of upstream global).
Indexes (or is it indices?) typically live in the source tree (they
don't need to).

* Searching - Once the code base is indexed, the indexes can be used
to search for symbol definitions as well as query locations where the
symbol is referenced. This can be done using the "global" binary
(again provided by upstream). Also there are various integrations with
commonly used editors - emacs, vim, elvis, etc - that internally
invoke global for their symbol lookup requirements. So if you are a
developer who would like to use global to navigate your way through a
large code base a common way to use it would be to use "gtags" and the
editor integration of your choice.

In addition to the above mechanisms, upstream also provides "htags"
which can be used to generate an HTML version of the index. "htags"
uses the index created by "gtags" and the source tree as input and
generates html files which allow you to navigate the source code in
the browser. By default, htags generates static pages which means you
can browse the code in a local browser without requiring a web server.

Optionally, "htags" can generate a dynamic index (which reduces disk
space usage) but requires an http server setup to be able to serve the
pages. In this scenario, you will also need to be able to execute CGI
scripts as the symbol lookup is done when serving the http request (as
opposed to pre-processed when using static pages).

And this last bit (integration with system web server) is the
functionality that had security concerns raised by Ron and for which
there are patches in the debian package. In recent versions (> 6.4,
Apr '15), upstream has dropped support for generating scripts that
expect to be written to system cgi-bin folder. As demonstrated by
wookey[1], it is still 

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

[Ian Jackson]

Wookey writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> OK, as Punit and I have prepared a current 6.5.5 which would be a
> candidate for a 'modern' release, and I think it's useful to have such
> a version available for people to test and file bugs against, I will
> do a 5-day delayed NMU to experimental. Putting it in experimental
> does not imply automatic transtion to stretch, nor block uploads via
> unstable, so seems a reasonable thing to do.
> 
> This version is not perfect, but it is current with updated
> packaging. I'll include details of the known issues in one of the
> 'please can we have a new version' bugs. I think it's more useful to
> have the current state of play avalable than for me to keep messing
> with it privately.

Hooray, thank you.

Ian.

-- 
Ian Jackson    These 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

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Bug#841294: Overrule maintainer of "global" to 
package a new upstream version"):
> E) the 'global' package is handed to other maintainer(s)
> 
> This would imply:
> 
>  - overruling the 'global' maintainer's decision (§6.1.4, implies
>3:1 majority in the TC vote);

No, handing the `global' package to other maintainer(s) would be a
decision under 6.1(2).  Quoting that section:

In cases where Developers need to implement compatible ...  stances
(for example, if they [Developers] disagree about [various things],
 ** or about who should be the maintainer for a package) **
the technical committee may decide the matter.

6.1(2) does not have a 3:1 requirement.

Ian.

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

[Wookey]

On 2016-11-23 18:19 +0100, Didier 'OdyX' Raboud wrote:
> The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up 
> the different outcome possibilities, which would help forming our opinions.
> Not all these options are exclusive, or would need an actual TC decision.
> 
> Here we go:
> 
> B) A fresher version of 'global' is uploaded to experimental 'soon'
>(with or without interested parties' help; with or without a TC decision)
> 
> This would imply:
>  - any interested party would file (and close) Debian bugs for issues and
>regressions (with appropriate severities), to make the 'fitness for a
>stable release' assessment easier, and earlier.

OK, as Punit and I have prepared a current 6.5.5 which would be a
candidate for a 'modern' release, and I think it's useful to have such
a version available for people to test and file bugs against, I will
do a 5-day delayed NMU to experimental. Putting it in experimental
does not imply automatic transtion to stretch, nor block uploads via
unstable, so seems a reasonable thing to do.

This version is not perfect, but it is current with updated
packaging. I'll include details of the known issues in one of the
'please can we have a new version' bugs. I think it's more useful to
have the current state of play avalable than for me to keep messing
with it privately.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

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

[Didier 'OdyX' Raboud]

The TC had an IRC meeting yesterday [0], and I (was) volunteered to wrap up 
the different outcome possibilities, which would help forming our opinions.
Not all these options are exclusive, or would need an actual TC decision.

Here we go:

A) 'global' stays maintained as it currently is.

This would imply:
 - no new 'global' upstream release before stretch,
 - no 'htags removal' warning in stretch,
 - possibility for the maintainer (and/or other interested parties) to start
   maintaining a 'global6'; this wouldn't offer any guarantee for a more
   recent version of 'global' in stretch. This would also imply having two
   'global' packages in certain suites.

B) A fresher version of 'global' is uploaded to experimental 'soon'
   (with or without interested parties' help; with or without a TC decision)

This would imply:
 - any interested party would file (and close) Debian bugs for issues and
   regressions (with appropriate severities), to make the 'fitness for a
   stable release' assessment easier, and earlier.

C) After the release of stretch, a fresher version of 'global' is uploaded to
   unstable with the explicit goal of making it available in buster.

This would imply:
 - any interested party would file (and close) Debian bugs for issues and
   regressions (with appropriate severities), to make the 'fitness for a
   stable release' assessment easier.
 - after migration to testing, this would make the fresher version of 'global'
   available for backporting to stretch-backports.
 - the version of 'global' released in stretch could carry 'htags removal'
   warnings;

D) A fresher version of 'global' is uploaded to unstable 'soon', targetting
   stretch (with or without interested parties' help; with or without a TC
   decision)

This would imply:
 - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
   in a TC vote);
 - any interested party (including the maintainer) would file (and close)
   Debian bugs for issues and regressions (with appropriate severities), to
   make the 'fitness for a stable release' assessment easier.
 - that this fresher version of 'global' would reach 'fit for release' status
   before the Stretch release.

E) the 'global' package is handed to other maintainer(s)

This would imply:
 - overruling the 'global' maintainer's decision (§6.1.4, implies 3:1 majority
   in the TC vote);

-- 
Cheers,
OdyX

[0] http://meetbot.debian.net/debian-ctte/2016/debian-ctte.
2016-11-22-16.59.html


signature.asc
Description: This is a digitally signed message part.

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

[Uoti Urpala]

On Mon, 21 Nov 2016 17:16:34 +1030 Ron  wrote:
> If we run with your proposal, what are you actually suggesting we tell
> the people who'd be upset by the loss of htags without notice in Stretch?
> Because I don't really see how you've addressed that here.
> 
> AFAICS, there's just either an implicit "Sucks to be you", or an
> implication that this is a simple "regression" which might be fixed
> by sending patches upstream.

Assuming the htags functionality really can't be supported with a newer
upstream version: tell people that the functionality is no longer
available in current GLOBAL. If someone - including you - thinks this
is a major problem and wants to provide an alternative, a fork
providing this functionality can be packaged. Under a name other than
"global".


> FWIW, I actually agree with a lot of the general rules of thumb that
> you outlined here, about how things should work in the normal case.
> But this isn't really a "normal" case, if it was we wouldn't be talking
> about this here at all.  What to do would be obvious to everyone.

There's nothing particularly "abnormal" about disagreeing with upstream
decisions. What is unusual, and is the reason why this has been
escalated here, is how badly you have handled the situation in your
packaging.


> The group complaining loudly now have basically squandered the entire
> release cycle by not reporting actionable bugs about what they need,
> and haven't sent any patches to remedy that.  And they are proposing

If anyone has "squandered the release cycle", it's you. You already
knew, or should have known, that the package was in an untenable state.
You've failed to fix the situation for years. You don't get to blame
other people for that.

> 

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

[Wookey]

On 2016-11-16 06:02 +1030, Ron wrote:
> On Mon, Nov 14, 2016 at 04:55:06PM +, Wookey wrote:
> > On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote:
> > > 
> > > 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.
> > 
> > It seems that it depends on the kernel source tree in use.
> 
> Just to clarify this here based on the details you provided when you
> later reported https://bugs.debian.org/844356, it turns out that it
> apparently doesn't depend on the kernel source tree or its version
> as such - what you saw happens when the source tree is polluted with
> infinite symlink loops, apparently due to a broken build script in
> this case.

Right. I was going to reply with that bug pointer here. 

It is an example of something that newer upstream versions cope with
without failing.

So is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756367 which I
have just confirmed is still a bug with 5.7.1, but not with 6.5.5
(There was a request earlier in this thread for actual issues with
5.7.1, that are fixed in newre releases, IIRC)

I added a note in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947 on that
packaging update.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

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

[Vincent Bernat]

 ❦ 15 novembre 2016 21:32 +0100, Tollef Fog Heen  :

> Vincent, would this be acceptable to you?

My understanding of Ron's mail is the following: do nothing now and wait
for Stretch release to see what version could be packaged. I am not
thrilled by this option (but I rank it above the "do nothing" option).

There was no upload for 6 years. A new version could be uploaded in
unstable before the release and blocked by an RC bug. Or to experimental
like suggested.
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Michael Biebl]

On Tue, 15 Nov 2016 21:32:38 +0100 Tollef Fog Heen  wrote:
> I think this sounds quite reasonable, all in all.  It gets us a newer
> version (albeit not for stretch, but I see the points about changing
> that so close to the freeze), it gives users some warning about htags
> going away (and if that's a huge problem, we can adjust course as we
> learn more).

Would it be possible to provide an new upstream release in experimental
(now) and have a 6.* based version in stretch-backports once stretch is
released?

As an outsider, who doesn't really use global but is just reading what's
going on here, this seems like it would satisfy almost everyone

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Tollef Fog Heen]

Hi,

apologies for the delay in responding here.

]] Ron

[…]

> I'd really like to keep this to just one package, for the reasons
> already given (though there's surely more if anyone still needs
> even more).

This sounds pretty reasonable to me.

> I'd really like to avoid "surprising" anyone unreasonably by pulling
> the rug out from under them with no time to usefully give us their
> own feedback too, and/or to contribute patches (here or upstream) to
> remedy that in some suitable way.  Not everyone does nothing when
> that is the option they are presented with.
> 
> I'd really like this to converge on a 'final' conclusion in a shorter
> timeline than "before we really run out of toy story release names
> forever".
> 
> And I'd really like it to have a strong enough technical basis and
> consensus that we can still stand by it even if there are a few
> people who do cry foul from the rough - however loudly or insistently.
> 
> Bonus points for minimising the risk of some unforeseen clusterfck
> emerging that we'll only be able to (try to) fix under the stricter
> freeze update rules, or that might mean we end up shipping with
> nothing at all for Stretch.

This all sounds reasonable to me.

> Given that we're now on both the cusp of the freeze and the silly
> season of the year where holidays and other rituals thin out the
> attention people have for other things until the new year, and
> that the smoother the freeze goes, the sooner we'll be out of it
> again after February, and that given how long this has already
> gone on for, that really isn't very far away ...
> 
> What I think is looking 'best', would be to once again extend the
> offer, to anyone whose joy is ruined by what we currently have,
> to accept (and/or help create) reasonable patches to what we
> currently have to fix that for them.  If you don't drag your feet
> on that, we should have plenty of time to review and upload those.

Ok.

> Then once the cycle begins for Stretch+1 early next year, we'll
> make the move to drop htags and pull in an audited new upstream
> release from whatever is current at the time.  Assuming it doesn't
> jump an entirely new and bigger shark in the meantime to add some
> other horrible disaster that we don't yet know about.
>
> That means we can start telling people _now_ to expect that will
> happen unless they can make a case otherwise.  And that anyone
> who doesn't get that memo will have a whole release cycle to
> see that it's gone, and try to make their case then.

Probably makes sense to add a warning anybody running htags now that
«this will be dropped in the next release», then.

> If nobody at all does that by the time Stretch+1 freezes, then
> we can have fairly good confidence in it being a 'final' answer.
> If they do, then again we actually have time to try and find a
> better solution before it becomes set in stone.  And we'll at
> least have given them about as fair a chance, with as much
> warning, as we ever reasonably can offer to do that.

Yup.

[...]

> I'm still open to listening to other suggestions, but if we have
> a sufficient consensus on this, and nothing better on the table,
> then, unless I've also missed some horrible showstopper, I think
> I'm willing to run with it.

I think this sounds quite reasonable, all in all.  It gets us a newer
version (albeit not for stretch, but I see the points about changing
that so close to the freeze), it gives users some warning about htags
going away (and if that's a huge problem, we can adjust course as we
learn more).

Vincent, would this be acceptable to you?

The rest of the committee: what do you think?  Is this an ok way
through?

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

[Ron]

On Mon, Nov 14, 2016 at 04:55:06PM +, Wookey wrote:
> On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote:
> > 
> > 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.
> 
> It seems that it depends on the kernel source tree in use.

Just to clarify this here based on the details you provided when you
later reported https://bugs.debian.org/844356, it turns out that it
apparently doesn't depend on the kernel source tree or its version
as such - what you saw happens when the source tree is polluted with
infinite symlink loops, apparently due to a broken build script in
this case.

Which is something lots of things will choke on, and there is an easy
workaround which most people should be using anyway if they are using
this on codebases of this size, to skip uselessly indexing the bulk of
the build tree where there is no source you want tags for.

But thanks for the good report in that bug about _what_ really went
wrong for you there.  This is useful information.


> ( I also found 844330 in the process, which is just a packaging update issue )

And thanks for the pointers to what changed with the emacs policy in
this one too.  That one was only evident if you actually had emacs
installed (which I don't), and which nobody else had so far reported.
It should be fixed in sid now though.

Good bug reports are the foundation for getting things fixed, so
thanks for setting a good example there.

  Cheers,
  Ron

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

[Wookey]

On 2016-10-25 07:29 +0200, Tollef Fog Heen wrote:
> ]] Wei Liu 
> 
> > 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.

It seems that it depends on the kernel source tree in use.
I just tried on a couple and found these reuslts:
~/debian/linux-4.0$ gtags
~/debian/linux-4.0$ global -s enable_dbg
arch/arm64/include/asm/assembler.h

4 files generated:
GPATH
GTAGS
GSYMS
GTAGS

~/debian/linux-3.16.7-ckt9$ gtags
gtags: directory stack over flow.
~/debian/linux-3.16.7-ckt9$ global -s enable_dbg
global: GSYMS not found.

only 2 files generated:
GPATH
GTAGS


global 6.5.4 (upstream release) works on both.


( I also found 844330 in the process, which is just a packaging update issue )

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

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

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> It's ok, we get it.  You've got an axe to grind, and boy are the sparks
> flying off it thick and hot!

My axe is the same one I often have in Technical Committee
discussions.  It is the axe of challenging the unaccountable power
exercised by despotic Debian package maintainers, within the fiefdoms
of their countless petty autocracies.

My axe is the axe that would chop aside the barriers erected by those
who dislike other people's software, and who use their position to
obstruct and to destroy.  My axe is the axe that would clear the path
for collaboration.

My axe is the axe of freedom for Debian's users and contributors.

Ian.

-- 
Ian Jackson    These 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

[Ron]

On Tue, Nov 08, 2016 at 04:56:40PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to 
> package a new upstream version"):
> > I made this timeline to show how Ron thinks it is appropriate to deal
> > with this package.
> > 
> > Messages to #574947 and #816924, combined
> > Each # is one email
> > Each P is one email containing a patch or link to updated package
> > Each U is one upload
> 
> I should say that this timeline drastically _under_represents the
> change in Ron's engagement with the technical problems in this
> package, following TC referral.
> 
> Many of his copious mails in the TC thread are each in themselves
> longer than _all his pre-TC mails on this topic combined_ !

It's ok, we get it.  You've got an axe to grind, and boy are the sparks
flying off it thick and hot!

The volume of private mail I've expended, over a much longer period than
is in than is in the public archives, at trying to find a resolution to
this dwarfs anything here too - so you might understand why I'm a little
tired of repeating it to people who are bringing nothing to the table.
Or why I didn't repeat it again to people who opened duplicates of the
original BTS thread.

So please just go take a cold shower or something, instead of wasting
everyone's time bloating this thread with hysterical foaming and
misrepresentation of what I actually said, and what people actually
need, that is irrelevant to us deciding _what_ the best compromise is
for what should be in any future package of this software.

I'm sure there's plenty of other even older bugs in the BTS which haven't
been fixed yet that you could spend some of your overzealousness on if
you're that desperate to vent your rage on things you've never contributed
to, or used, or taken the time to understand.


Unless you're just trying to bury the embarrassment of your previous
hasty post under a mountain of stuff people's eyes will glaze over on.
In which case, knock yourself out.  I guess.  It's your permanent record.

But I've got Real Work to do, and we've got a release freeze looming,
and wasting time on being bullied by you isn't helping any of that.

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

[Uoti Urpala]

On Tue, 8 Nov 2016 15:33:32 +1030 Ron  wrote:
> On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> > It seems you're only interested in impartial and non-partisan voices
> > when they happen to back your position. I am impartial and non-partisan,
> > and formed my opinion by reading the bugs and your emails.
> 
> And "your opinion" still hasn't said even a single word to show that you
> understand the technical problem here, or to offer any solution to it.
> The problem which doesn't just magically go away regardless of who might
> implement it.

Even if your technical concerns were correct, they do not justify your
handling of the package. Saying that your actions have been wrong, and
the package needs to be handled differently, does not require
addressing the technical CGI issues in any way. You have no basis to
insist that people care about the CGI issue or try to solve it before
commenting on other handling of the package.


> > If you indeed welcome opinions from people like me, your statements
> > above are a little odd.
> 
> I think you missed the bit about "comprehending the problem and building
> consensus on solutions" - because if this is all you have to offer then
> no, "opinions" from people "like you" are neither helpful nor welcome.
> Even if they 100% agree with me.  They are just a toxic symptom of people
> still ignoring the hard technical problem.

"The problem" here is the way you've blocked the package at an ancient
version. Fixing this does not require creating a perfect CGI framework
or in any other way fixing all upstream issues and making the software
perfect. Maybe _you_ really care about the CGI issue. But if nobody -
including you - cares enough to create a perfect solution, then it'll
be broken. Too bad, but even if you're really disappointed, holding the
package indefinitely at an obsolete version is not an acceptable
response. Again, that nobody has created a perfect upstream does not
justify your handling of the package, and you don't get to blame others
or call their behavior "toxic" because of that.


> details of _what_ we ought to do.  If we don't solve that, then who does
> it is kind of irrelevant, there'll still be a Hard Problem that someone
> won't be happy with.

You keep talking about Hard Problems and how others must solve them to
be allowed to criticize your actions or actually do anything to change
the status quo that you've failed to improve for several years. That's
bullshit. If someone packages a new upstream without solving those
issues, that'll be perfectly acceptable. Fixing software to be perfect
is not a requirement for packaging, and creating a package that lacks
some desired functionality when upstream lacks it is OK. The way you've
handled the package is not OK.

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

[Ian Jackson]

Ian Jackson writes ("Re: Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> I made this timeline to show how Ron thinks it is appropriate to deal
> with this package.
> 
> Messages to #574947 and #816924, combined
> Each # is one email
> Each P is one email containing a patch or link to updated package
> Each U is one upload

I should say that this timeline drastically _under_represents the
change in Ron's engagement with the technical problems in this
package, following TC referral.

Many of his copious mails in the TC thread are each in themselves
longer than _all his pre-TC mails on this topic combined_ !

Ian.

-- 
Ian Jackson    These 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

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> On Tue, Nov 08, 2016 at 02:52:29PM +, Ian Jackson wrote:
> > Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
> > upstream version"):
> > > I think you missed the bit about "comprehending the problem and building
> > > consensus on solutions"
> > 
> > Somehow I missed the part where you helped contributors to "comprehend
> > the problem" and enabled them to "build consensus on solutions"
> > between March 2010 and mid-October 2016.
> 
> Yes, you did.  And you managed to miss it despite the fact I gave links
> to the public discussions in my first reply here and that other people
> in those have referred to the private discussions we had too.

I assume you are talking about:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166

These are the only two references I could find in the whole of this
bug (#841294) from you to your own earlier messages.  In fact #574947
contains only FIVE responses from you over a period of SIX YEARS.
#816924, filed in March 2016, contains none.

It is true that 574947#131, in April 2014, contains an explanation of
an underlying technical difficulty.  But it also contains a strong
NAK, and this wording:

   I am very interested in seeing this all fixed, but someone is going to
   have to find a middle ground that both meets the minimum sensible
   expectations for distro Best Practice for this, and that Shigio is
   willing to accept.  Several of us have tried several times, but maybe
   you will have more luck with that.

It is not appropriate for the Debian maintainer to firmly NAK at the
same time as asking contributors to set direction.  574947#166 is,
like most of your messages, a very short mail saying "please fix it"
without any proposed technical approach.

I do not deny that there is an underlying technical difficulty.  But
in the absence of someone doing some substantial engineering to make
the questionable upstream feature packageable, there is a simple
choice:

Either we stay with the current, ancient version; or we disable the
troublesome feature (or ship it in a broken state, where it is
necessary to be root to use it).

The tradeoff you have chosen is to privilege hypothetical users of a
niche feature, in favour of a clamour of users wanting the benefits of
the new upstream version.

Ian.

-- 
Ian Jackson    These 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

[Ron]

On Tue, Nov 08, 2016 at 02:52:29PM +, Ian Jackson wrote:
> Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
> upstream version"):
> > I think you missed the bit about "comprehending the problem and building
> > consensus on solutions"
> 
> Somehow I missed the part where you helped contributors to "comprehend
> the problem" and enabled them to "build consensus on solutions"
> between March 2010 and mid-October 2016.

Yes, you did.  And you managed to miss it despite the fact I gave links
to the public discussions in my first reply here and that other people
in those have referred to the private discussions we had too.

I'm impressed.  Or are you seriously suggesting that I ought to have
repeated all of that, every time, to every person who said "me too"
without adding anything new to the discussion or situation?

But thanks for adding one more example of how trivial it is to play
the blame game when you have nothing of value to add for actually
helping to make thing better - and for making it clear that many of
the people doing that are being agitated to by others rather than
having any real interest in the quality of what Debian ships.

  Clap, clap.

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

[Ian Jackson]

Ron writes ("Bug#841294: Overrule maintainer of "global" to package a new 
upstream version"):
> I think you missed the bit about "comprehending the problem and building
> consensus on solutions"

Somehow I missed the part where you helped contributors to "comprehend
the problem" and enabled them to "build consensus on solutions"
between March 2010 and mid-October 2016.

No, wait, that's because you didn't.  You basically just said "no".

Maintainership of this package should be transferred to maintainer(s)
who are capable of encouraging and leading a community, rather than a
maintainer who simply obstructs (and only responds with fine words
when is a threat to their authority).

The leadership aspects of maintainership are the only essential
capacities of a Debian maintainer and with respect to this package,
your record is of failure.

It is obvious that there are a variety of possible technical
approaches, most if not all of which are better than maintaining the
status quo for half a decade.  I have confidence that if the package
were wrested from your control, and the petitioners made maintainers,
the technical aspects would be resolved adequately.

The real problem here is not technical.  This is a management failure.

Ian.

Full disclosure:

 * I know Wei Liu as a work colleague and friend and encouraged him to
   participate in this bug report;

 * As Ron may remember, I previously encountered him in a previous
   situation that came before the TC, relating to codecs and mumble.
   It's some years ago now but IIRC I found myself disagreeing with
   Ron.

 * I have formed my opinion about `global' by reading the bug logs.

-- 
Ian Jackson    These 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

[Ron]

On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> On Nov 07 2016, Ron  wrote:
> 
> > I've taken the time to repeat this all again now, because regardless
> > of how it got here, I actually have some faith in the new face of the
> > TC as a forum for building 'project wide' consensus around hard problems.
> > Having read all of that, Phil has now asked me to propose a concrete
> > alternative to what he suggested, which I did. And I think the important
> > difference is that we have the opportunity to build a consensus here
> > which includes a good proportion of impartial and non-partisan voices who
> > weighed up all the options like I've been doing.
> 
> It seems you're only interested in impartial and non-partisan voices
> when they happen to back your position. I am impartial and non-partisan,
> and formed my opinion by reading the bugs and your emails.

And "your opinion" still hasn't said even a single word to show that you
understand the technical problem here, or to offer any solution to it.
The problem which doesn't just magically go away regardless of who might
implement it.

And now you say that apparently you didn't even read the conversation that
you interjected into enough to notice that Phil and I were having a civil
discussion precisely on the _difference_ we saw in ways that this might be
'solved' ...

All you did was dismiss and (continue to) try to side track that.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#155
(for anyone who missed it before people tried to bury it piling on to
the man again)


> If you indeed welcome opinions from people like me, your statements
> above are a little odd.

I think you missed the bit about "comprehending the problem and building
consensus on solutions" - because if this is all you have to offer then
no, "opinions" from people "like you" are neither helpful nor welcome.
Even if they 100% agree with me.  They are just a toxic symptom of people
still ignoring the hard technical problem.


Which is very different from the suggestions of people, say, "like Phil",
where no matter how much we disagree at the outset, we can still focus
that on looking at the merits of ways to solve the problem as best we
can in the circumstances that we have.  And try to come to some sort of
best consensus on it.

When you understand that distinction, and have something we've all missed
to contribute, _then_ you'll be welcome, whoever you're disagreeing with.

If all you want to do is play "Trump school of debate", then please take
that somewhere else, and leave this thread to focus on the technical
details of _what_ we ought to do.  If we don't solve that, then who does
it is kind of irrelevant, there'll still be a Hard Problem that someone
won't be happy with.


  Ron

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

[Nikolaus Rath]

On Nov 07 2016, Ron  wrote:
>> In my opinion, the fact that you had no time for this issue for multiple
>> years, but are now able to send a large number of long emails about it
>> to the ctte does not speak in your favor.
>
> I'm sorry, remind me again about where and what you have ever tried
> to offer that would be of value to resolving this which I didn't
> respond to?
>
> Because I've had countless detailed discussions with people who have,
> and I don't recall you ever being part of any of that.

[...]

> I've taken the time to repeat this all again now, because regardless
> of how it got here, I actually have some faith in the new face of the
> TC as a forum for building 'project wide' consensus around hard problems.
> Having read all of that, Phil has now asked me to propose a concrete
> alternative to what he suggested, which I did. And I think the important
> difference is that we have the opportunity to build a consensus here
> which includes a good proportion of impartial and non-partisan voices who
> weighed up all the options like I've been doing.

It seems you're only interested in impartial and non-partisan voices
when they happen to back your position. I am impartial and non-partisan,
and formed my opinion by reading the bugs and your emails. If you indeed
welcome opinions from people like me, your statements above are a little
odd.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

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

[Vincent Bernat]

 ❦  7 novembre 2016 16:45 +1030, Ron  :

> I've always given time to anyone who took the time to understand and
> showed an interest and willingness to try something new to improve
> this. And it's clear that the person who gave the most recent (and
> best) feedback to the original bug found it easy enough to clearly
> understand the situation from what was already written there:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190

A message that received absolutely no answer (and quite similar to the
other reports: doesn't work with current version, works with the new
upstream version, kthxbye).

> Vincent brought this here after contributing nothing more constructive
> or indicative of understanding than stamping his feet and insisting
> "I want a new upstream and I want it now.  And I want someone else
> to do the work".

"Now" was three years ago. My last message in the above bug report [0]
was also received with a silence on your side. There are 15 people in
the thread asking for a new upstream version. Several of them proposed
patches to package a new version. None of them get an answer from
you. Nobody will help debug an issue and build a patch on an 8 year old
software while there are new versions available.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Ron]

On Sun, Nov 06, 2016 at 05:09:56PM -0800, Nikolaus Rath wrote:
> On Nov 06 2016, Ron  wrote:
> > On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
> >> Ron  writes:
> >> >
> >> > I can try to clarify that if there's a question in your mind that
> >> > you don't think I touched on there.
> >> 
> >> The question that remains is what you actually intend to do.
> >
> > Nod.  So far here, I've mostly tried to stick to just outlining the
> > facts we have to deal with, and the options I think we have and the
> > pros and cons of them - because I don't have a preconceived answer
> > to that which I'm welded to, and I was more interesting in listening
> > to well considered comments that people might have had than turning
> > this into a mindless tug of war between two inflexible positions.
> 
> It's too bad that you only started doing this after this was escalated
> to the CTTE. Had you responded at such length and with so little delay
> to the earlier bug reports, the situation would be very different. But
> now, your sudden communicativeness just has the opposite effect.
> 
> In my opinion, the fact that you had no time for this issue for multiple
> years, but are now able to send a large number of long emails about it
> to the ctte does not speak in your favor.

I'm sorry, remind me again about where and what you have ever tried
to offer that would be of value to resolving this which I didn't
respond to?

Because I've had countless detailed discussions with people who have,
and I don't recall you ever being part of any of that.

Just repeating myself over and over to people who clearly weren't
interested in helping with what was needed to solve the Hard parts of
this, proved itself time and again to be an insane hope.  I'm sorry
for you if what you spent a few minutes skimming over didn't show
that to you before you decided to pick up a stone and throw it.

I've always given time to anyone who took the time to understand and
showed an interest and willingness to try something new to improve
this. And it's clear that the person who gave the most recent (and
best) feedback to the original bug found it easy enough to clearly
understand the situation from what was already written there:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#190

Which part of that did you not understand?


If you want to understand reality, then you ought to understand
that it's drive-by mud slinging like yours which have led to a lot
of capable developers simply unsubscribing from most or all of
Debian's mailing lists to avoid getting mired in them.

And it's aggressive prejudice like Ian's, and the people who thought
they could (ab)use it to get their way in an argument which led to a
lot of people losing trust in the TC to actually do Good Things.

Vincent brought this here after contributing nothing more constructive
or indicative of understanding than stamping his feet and insisting
"I want a new upstream and I want it now.  And I want someone else
to do the work".


I've taken the time to repeat this all again now, because regardless
of how it got here, I actually have some faith in the new face of the
TC as a forum for building 'project wide' consensus around hard problems.
Having read all of that, Phil has now asked me to propose a concrete
alternative to what he suggested, which I did. And I think the important
difference is that we have the opportunity to build a consensus here
which includes a good proportion of impartial and non-partisan voices who
weighed up all the options like I've been doing.  People who will have my
back to say this was well thought through, if and/or when other people
start making contentless complaints like you are about whatever the new
state ends up being, and taking sides, and throwing more stones.  People
whose time is potentially valuable and shouldn't be wasted.  I'm looking
at this as a test of how the TC might be able to function like that as
much as anything else, and I think that's worth a bit of the time that
I have to give to Debian.


So if this is the best analysis you are capable of sharing based on all
of what has been written about this - then indeed you will have to just
forgive me and learn if I henceforth don't continue to respond to your
comments when they add nothing to the solution.  The way you make time
to engage in things that might really make a difference is to not waste
it on things that obviously won't.

I can't make you want to learn and think.  But I hope that one day
you'll understand that you're bringing nothing to the discussion
but distracting noise if you don't.  In the meantime, can we first
please stay focussed on solutions to the _problem_ instead of just
childishly attacking the man stuck on the pointy end of it.

This is already hard enough without also having to set the record
straight about ignorant slurs on what I have or haven't done and
uninformed speculation about why ...  that sort of nonsense isn't

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

[Nikolaus Rath]

On Nov 06 2016, Ron  wrote:
> On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
>> Ron  writes:
>> >
>> > I can try to clarify that if there's a question in your mind that
>> > you don't think I touched on there.
>> 
>> The question that remains is what you actually intend to do.
>
> Nod.  So far here, I've mostly tried to stick to just outlining the
> facts we have to deal with, and the options I think we have and the
> pros and cons of them - because I don't have a preconceived answer
> to that which I'm welded to, and I was more interesting in listening
> to well considered comments that people might have had than turning
> this into a mindless tug of war between two inflexible positions.

It's too bad that you only started doing this after this was escalated
to the CTTE. Had you responded at such length and with so little delay
to the earlier bug reports, the situation would be very different. But
now, your sudden communicativeness just has the opposite effect.

In my opinion, the fact that you had no time for this issue for multiple
years, but are now able to send a large number of long emails about it
to the ctte does not speak in your favor.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

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

[Uoti Urpala]

Note: this is written as an outsider who doesn't have any direct stake
in the issue.

On Sun, 6 Nov 2016 05:00:12 +1030 Ron  wrote:
> > And I think the latter is basically what the "just ship multiple
> versions and hope the future gets clearer" option boils down to.
> All it really does is take the pressure off of everyone but me
> to have any interest at all in actually trying to resolve the
> genuinely Hard part of this.  And it does that by making an even

I don't think the others have any obligation to try to resolve any
technical issues, and it is 100% reasonable of them to insist that
Debian just ship a new upstream version (as long as the packaging is
not otherwise unacceptably bad; but simply disabling any functionality
that is not secure or otherwise OK upstream is a valid answer).

Based on what I've seen in this thread, I think I can say you're
clearly in the wrong. And that does not require considering any of the
technical issues with the software. The software now shipped in Debian
as "global" is simply too outdated compared to upstream. That you have
technical objections to something in the newer versions could be a
reason for you to create a new fork. But you have not properly done
that, and abusing your Debian packager position to indefinitely hold
back the package is not an appropriate answer to any technical issues,
regardless of the validity of the technical objections.

To properly create a fork, you'd need to either pick a new name for
your fork, or contest whose version has the right to the name "GLOBAL".
You have obviously not chosen a new name. You don't seem to be claiming
to be the overall upstream maintainer of GLOBAL either, and claiming
that would be totally inappropriate if you're only shipping your
version in Debian. As such, you have no business shipping your version
under the "global" package name. Either ship the upstream version -
even if flawed and causing problems for some users - or use another
package name.

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

[Ron]

On Thu, Nov 03, 2016 at 09:20:30AM +0100, Philip Hands wrote:
> Ron  writes:
> >
> > I can try to clarify that if there's a question in your mind that
> > you don't think I touched on there.
> 
> The question that remains is what you actually intend to do.

Nod.  So far here, I've mostly tried to stick to just outlining the
facts we have to deal with, and the options I think we have and the
pros and cons of them - because I don't have a preconceived answer
to that which I'm welded to, and I was more interesting in listening
to well considered comments that people might have had than turning
this into a mindless tug of war between two inflexible positions.

There's some things I think it's obvious that we shouldn't do, and
some things I think we shouldn't do which might not have such a
clear consensus - but that's not enough on its own to make it clear
what we _should_ do, and I agree with you that if the fresh input we
are getting here is tailing off, then it's probably on my head to
make a suggestion now that we can consider the merits of.

I have been chewing over how various options might pan out, to try
and decide what I think looks the Least Bad overall, for both the
immediate gratification people and in the long term.  But I wanted
to give everyone who wanted it a chance to weigh in with their own
ideas, and I wanted to have a good look at what had actually changed
on the ground with the latest upstream changes - without having that
get short-circuited by people who didn't want to put in any work to
look in detail crying "your idea sucks, I demand satisfaction" again.

I can sympathise with their pain, but it's a poor train of logic to
base any sort of hard decision on.


> You went into some detail about why the existing popcon figures should
> not be relied upon, which is fair enough but seems not to take account
> of the fact that my suggestion was for you to create a new global5
> package which would not be automatically pulled in by anything (unless
> the maintainers of reverse dependencies decide that it's better to
> switch to depending upon global5, which should probably be
> strongly discouraged).

Sorry if I confused those two things there.  The issues with what we
can extrapolate from existing popcon numbers wasn't really related to
your suggestion at all.  But it seemed like something that needed a
bit of light shone on it, since a few people had made arguments based
on "because popcon".  You didn't do that, but at least one of the
comments after yours did it again.

I probably should have kept that more clearly separate.


> The popcon figures for global would then still be contaminated with
> whatever dragged it in in the first place, but the figures for global5
> would tell you the extent to which the userbase of the global5-only
> features actually exists.

Yeah, I did see the logic you were working through there, but I thought
the other reasons for why 'solving' this by just turning it into two
conflicting packages, both with a tiny number of users, would be strong
enough to stand on their own without a detailed analysis of what that
part might (or might not) usefully add for us.


> Either there are real users for those features, which might persuade you
> that the effort of backporting features to global5 is justified -- in
> that case the exit strategy would be for the patched global5 to be the
> final inheritor of the 'global' package (in stretch+1 say,

So to answer that part more directly, I think the big problem with just
this part of it, is that popcon is a fairly strongly lagging indicator
(which the 'spike' fairly clearly does show, it took ~3 years to peak,
and even longer than that to subside again) - so to use it as a 'nail
in the coffin' metric, really we'd be looking at more like stretch+2
or even (much) later - which realistically, becomes a fair approximation
for "we will never make a decision based on this", even if we discount
guessing what proportion of people using this also use popcon on the
machines they use it on, to decide if it's a relevant metric at all.

I think in that sort of time frame, the probability of something else
substantive changing, which would make this even less certain or less
useful, is comparatively high.

Basically, we'd be resigning ourselves to saying "this will be a mess
forever", and an even bigger mess in Debian.  Which is why that's
not my first preference here.  The value of Debian is in making the
messy outer world less messy where possible.  Not in making it a
dumping ground for the spoils of indecision about how to deal with
that.


> replacing the v6 package once you have the relevant feature parity).

To do that still needs the people affected to actually tell us what
the 'relevant' features they want parity with are.  And if they did
that, we could have solved that part of it 'overnight' at any time
in the last or next few years.

Until someone complaining about that puts their hand up to do even
the minimal 

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

[Philip Hands]

Ron  writes:

> Hi Marga,
>
> On Tue, Nov 01, 2016 at 11:32:49AM +0100, Margarita Manterola wrote:
>> > Philip Hands  writes:
>> > It seems like you are tempted to drop htags anyway now, so calling the
>> > version 6 package 'global' and adding the global5 package to give people
>> > an escape route seems like the right thing to do.
>> > 
>> > That also makes it much easier to detect when people cling to version 5,
>> > since there will only be intentional installations of that package.
>> 
>> I second this proposal by Phil.  It seems to me that this is the most 
>> reasonable
>> outcome, given the current situation. This means that global gets updated to 
>> the
>> latest version, with a NEWS message stating that htags functionality has been
>> removed and that users that care about htags should install global5 instead.
>> 
>> Ron, you haven't replied to this proposal yet. Can you state your opinion
>> regarding this?
>
> Did I mess up on the CC for that somehow?  Or was there something I
> didn't address about the question(s) of going this way in:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#135
>
> I can try to clarify that if there's a question in your mind that
> you don't think I touched on there.

The question that remains is what you actually intend to do.

You went into some detail about why the existing popcon figures should
not be relied upon, which is fair enough but seems not to take account
of the fact that my suggestion was for you to create a new global5
package which would not be automatically pulled in by anything (unless
the maintainers of reverse dependencies decide that it's better to
switch to depending upon global5, which should probably be
strongly discouraged).

The popcon figures for global would then still be contaminated with
whatever dragged it in in the first place, but the figures for global5
would tell you the extent to which the userbase of the global5-only
features actually exists.

Either there are real users for those features, which might persuade you
that the effort of backporting features to global5 is justified -- in
that case the exit strategy would be for the patched global5 to be the
final inheritor of the 'global' package (in stretch+1 say, replacing
the v6 package once you have the relevant feature parity).

Alternatively, if very few people install global5, you can publish an
update that reminds people that the package is going away, and asking
them to tell you why they might be upset about that, and then you either
get useful feedback, or you can remove the package with a clear
conscience.

I would think that this is a strategy that would allow you to act.

Perhaps you can explain why you apparently think doing nothing
indefinitely is better for our users.

I am aware that there are subtleties here that I may have missed, so
please don't assume that I'm intentionally ignoring what you think of as
the obvious flaws with this idea.

I really don't mind being treated as an ignoramus.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Ron]

Hi Marga,

On Tue, Nov 01, 2016 at 11:32:49AM +0100, Margarita Manterola wrote:
> > Philip Hands  writes:
> > It seems like you are tempted to drop htags anyway now, so calling the
> > version 6 package 'global' and adding the global5 package to give people
> > an escape route seems like the right thing to do.
> > 
> > That also makes it much easier to detect when people cling to version 5,
> > since there will only be intentional installations of that package.
> 
> I second this proposal by Phil.  It seems to me that this is the most 
> reasonable
> outcome, given the current situation. This means that global gets updated to 
> the
> latest version, with a NEWS message stating that htags functionality has been
> removed and that users that care about htags should install global5 instead.
> 
> Ron, you haven't replied to this proposal yet. Can you state your opinion
> regarding this?

Did I mess up on the CC for that somehow?  Or was there something I
didn't address about the question(s) of going this way in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#135

I can try to clarify that if there's a question in your mind that
you don't think I touched on there.

  Cheers,
  Ron

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

[Margarita Manterola]

> Philip Hands  writes:
> It seems like you are tempted to drop htags anyway now, so calling the
> version 6 package 'global' and adding the global5 package to give people
> an escape route seems like the right thing to do.
> 
> That also makes it much easier to detect when people cling to version 5,
> since there will only be intentional installations of that package.

I second this proposal by Phil.  It seems to me that this is the most reasonable
outcome, given the current situation. This means that global gets updated to the
latest version, with a NEWS message stating that htags functionality has been
removed and that users that care about htags should install global5 instead.

Ron, you haven't replied to this proposal yet. Can you state your opinion
regarding this?

Thanks!

-- 
Regards,
Marga

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

[Ron]

On Tue, Oct 25, 2016 at 09:03:40AM +0200, Philip Hands wrote:
> Ron  writes:
> 
> ...
> > 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.
> 
> This sounds like, if you were given enough feedback, you'd be willing to
> fork this to keep the old functionality available, while servicing the
> needs of users of new features -- is that right?

I definitely think that's an option we'd be silly to take off the table
before we had enough information to determine that it wasn't a very
practical choice from here on out.

I'd already forked it (with upstream's blessing that this was how we
should do it) to add the extra functionality that was needed before the
very first upload of it in 1999 - and have been maintaining that fork
ever since.  The only thing that changed was upstream made it impossible
to just pull all of their new changes in verbatim without breaking what
we already had.  But my hope had always been that eventually user demand
communicated to upstream would lead us to find some common ground on that
again, one way or another, and we'd get past that stalemate.

For anything I maintain, I'm always willing to carry and/or write sensible
patches that fix real problems people are having.

In this case, it potentially really wouldn't be any different to carrying
backported patches from an 'unstable' upstream branch to a stable release
package - which isn't exactly an uncommon practice.  I do that all the
time with software I'm upstream for, and the distro is full of packages
doing exactly that.

That certainly seemed like an easy option for Vincent's ggtags problem.
The new options added to gtags seem mostly pretty trivial, but I never
got (and still don't have) a clear answer about whether that is actually
the problem with it or not, and if so, what extra options it actually
needs.  For all I know at this stage, the incompatibility is related to
something else entirely.  Maybe the output formatting changed or some
thing like that.  I don't know if it's "completely" broken, or if some
minor feature of it just has a glitch.

When he said he wasn't interested in investigating it, there didn't seem
to be much point hounding him to do that. If it really was a widely used
front end, someone else would eventually come along who was interested
in digging a bit deeper to fix it.  Historically, that's how this sort
of thing usually works.


> If that is the case, and having read the rest of what you've written, it
> seems that the clamour for upgrading to the latest release is a symptom
> of not paying sufficient attention to the messy details.

Yes, there is an element here of what a friend of mine often complains
about with getting her IT staff to fix problems.  All they ever say is
"we're waiting for a new upstream release".

Which isn't to say I'm convinced yet that this is the right option for
us to go with from here - but I think if we're going to weigh up the
pros and cons of each, knowing there is no one clear right choice that
is certain to make everyone happy, then it's one that we shouldn't rule
out before we know if there is some real showstopper that makes it look
obviously worse than the other alternatives.

Either way, it *is* a thing we could do Right Now, without having to
wait on coming to some consensus about what the long term future
ought to be.  Fixing things that don't break anything else is about
the only no brainer that we do have here.


> > 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.
> 
> How viable is it to have two conflicting packages:
> 
>   global5: continuing as you have it now
>(perhaps with patches to make it work for recent use cases)
> 
>   global6: (with htags support removed)
> 
> If you did that, and especially if you changed a config file to include
> a note that the global5 package might go away in the next release (so
> that most people will see that on upgrade) then you could provoke
> the feedback you want, and perhaps also make judgements based on the way
> popcon figures shift over time.

My hunch is that this would be about as wildly successful 

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

[Wei Liu]

On Tue, Oct 25, 2016 at 6:29 AM, Tollef Fog Heen  wrote:
> ]] 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.
>

Sure, if it works for you. That's great.

I couldn't go back in time to extract a backtrace or coredump. It
could be that I was so unlucky that at the time my computer was
constantly hit by cosmic rays that it just couldn't cope with that
version of global. I installed a new version of global since then and
never looked back. But at some point I decided I cared enough to check
the situation of global in Debian again. I scraped all information I
could find and that led to #816924 (which is the reason I know about
this CTTE bug, BTW).

It is entirely possible that all reporters who said global didn't work
were all out-liners. It is entirely possible that there are hundreds
(based on popcon data) of satisfying Debian global users in the wild.
They just don't speak up because there is nothing to report.

I can only reason from first principle: there is a reason why a new
release is made. Either there are new shiny features, or there are
bugs to fix, most likely to be both. I don't believe the current
Debian global is free of bugs, and I believe it would serve Debian
best if we move on from this ancient version.

If some sort of objective metric is needed, I suggest we wait until
popcon number drops to zero, however long it takes. I'm absolutely
fine with that. :-)


Wei.


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

[Philip Hands]

Philip Hands  writes:

...
> How viable is it to have two conflicting packages:
>
>   global5: continuing as you have it now
>(perhaps with patches to make it work for recent use cases)
>
>   global6: (with htags support removed)

Ah, I see -- I had somehow got the impression that the first was already
called global5 from comments in the thread.  Given that it's actually
called 'global' I guess that adds an extra wrinkle.  Depending upon your
preference I would expect that you select one or other version to be the
inheritor of the global name.

It seems like you are tempted to drop htags anyway now, so calling the
version 6 package 'global' and adding the global5 package to give people
an escape route seems like the right thing to do.

That also makes it much easier to detect when people cling to version 5,
since there will only be intentional installations of that package.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Philip Hands]

Ron  writes:

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

This sounds like, if you were given enough feedback, you'd be willing to
fork this to keep the old functionality available, while servicing the
needs of users of new features -- is that right?

If that is the case, and having read the rest of what you've written, it
seems that the clamour for upgrading to the latest release is a symptom
of not paying sufficient attention to the messy details.

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

How viable is it to have two conflicting packages:

  global5: continuing as you have it now
   (perhaps with patches to make it work for recent use cases)

  global6: (with htags support removed)

If you did that, and especially if you changed a config file to include
a note that the global5 package might go away in the next release (so
that most people will see that on upgrade) then you could provoke
the feedback you want, and perhaps also make judgements based on the way
popcon figures shift over time.

Would that work for you?  

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Punit Agrawal]

On Sun, Oct 23, 2016 at 7:49 AM, Ron  wrote:
> On Sat, Oct 22, 2016 at 05:41:54PM +0200, Vincent Bernat wrote:
>>  ❦ 22 octobre 2016 14:44 +1030, Ron  :
>>

[...]

>
> Without repeating what I already said above about this option, we do
> already have some evidence about how well it might be implemented in
> practice ...
>
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176
> Punit (who you were proposing to take this over if the TC agreed with
> you about that being the best option) said:
>
>  While there doesn't seem to be any motivation to resolve the issues
>  blocking the package upgrade, I'd like to point you to a package
>  repository containing an upgrade to recent upstream release (6.2.12) -
>
>  http://anonscm.debian.org/gitweb/?p=collab-maint/global.git.
>
>  The package is also updated to follow more recent packaging standards.
>
>  It would be ideal if the official package got upgraded (or maybe
>  replaced by another package), but in the meanwhile I'd like to keep
>  the above repo in-sync with upstream releases. Please let me know if
>  you face any issues using that version.
>
>
> Anyone want to take a bet on guessing the last time that repo was
> "in-sync with upstream releases"?
>
> If you guessed "about a week before that email was sent ...", then
> yeah, you win the "I've seen this before too" booby prize.
>
> It's now something like 12 releases and more than 2 years behind
> being "in-sync with upstream", and hasn't been touched again at all
> since then ...

Seeing that I wasn't getting a clear response on what the problem
blocking the upgrade is and how to resolve it, I didn't spend any
effort on the repository.

As I don't use htags (or the related cgi-bin functionality) I was
looking for guidance on what is needed to fix/resolve the issue with
newer upstream releases. The reason I wanted to see the package
upgraded was because the existing version didn't  work for me on the
linux kernel source tree (while upstream does). Forgive me for not
being either a debian or a source code tagging software expert.

If only you'd engaged with the commentators of #574947 and #816924, we
wouldn't be here trying to point fingers.

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

[Vincent Bernat]

 ❦ 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

[Tollef Fog Heen]

]] 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

[Tollef Fog Heen]

]] 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

[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;

 * 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 Jackson    These 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

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

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

[Ron]

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

[Don Armstrong]

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

[Vincent Bernat]

 ❦ 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

[Don Armstrong]

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

[Ron]

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 - 

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

[Ian Jackson]

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 Jackson    These 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

[Ron]

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 

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

[Tollef Fog Heen]

]] 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».

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.

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.

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

[Vincent Bernat]

 ❦ 23 octobre 2016 19:53 +1030, Ron  :

>> So, nothing will move on your side until I bring some proof that "nobody
>> is interested in htags". Well, I won't bring any such proof either.
>
> That was a claim _you_ made in bringing this to the TC.  Are you really
> saying now that you have no basis at all for making it?

There are several people (15 of them) in both bug reports asking for a
new upstream release. None of them said they were using the CGI
stuff.

>> Your mail should show the TC you don't intend on bringing any solution
>> other than the status quo.
>
> That isn't what I said at all.  What I'm saying is that there is no way
> we can avoid _some_ potential user not losing here, whatever we do.
> That's just a plain and simple and awful fact of the situation.
>
> So if you don't want to be the one who loses from whatever consensus
> we do arrive at as the best of a bunch of bad options, you're probably
> going to need to present a slightly more compelling argument than
> "I can't be bothered doing any work to help decide what's really best".
>
> Trying to play procedural games and hoping that luck might fall your
> way because you threw the dice is really not very helpful for making
> a good technical decision here.
>
> 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.  But I'm happy to talk it out here and see if we
> can arrive at some informed consensus, even if it's only so that we
> can have some more independent and objective input to put an end to
> the "ooh, that nasty maintainer won't do what I want" side of it.

Let's see what the TC thinks. I don't have more arguments to bring to
this debate.
-- 
When one burns one's bridges, what a very nice fire it makes.
-- Dylan Thomas


signature.asc
Description: PGP signature

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

[Ron]

On Sun, Oct 23, 2016 at 09:55:43AM +0200, Vincent Bernat wrote:
>  ❦ 23 octobre 2016 17:19 +1030, Ron  :
> > If you're saying yes to the question I put above, then what I'm asking
> > is: what real evidence can you show to back up your assertion that
> > "nobody cares about htags", and/or what compelling case can you make
> > that breaking things for anyone who does use it is a lesser evil than
> > the problem(s) you are experiencing, and actually a necessary evil to
> > fix your problem.
> 
> I don't have any evidence.
> 
> > If ggtags is broken, that's a bug in ggtags.
> 
> ggtags relies on contemporary versions of its dependencies. Not
> something that most people will call a bug. But I don't have evidence on
> this either. People in the bug report don't complain just to have a new
> shiny number in "global --version". They have actual problems with the
> version currently in Debian.

That actually effectively _is_ what you are saying if all you can say
about this is "ggtags relies on a new shiny number" and not tell us
anything at all about why.


> > Without repeating what I already said above about this option, we do
> > already have some evidence about how well it might be implemented in
> > practice ...
> >
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176
> > Punit (who you were proposing to take this over if the TC agreed with
> > you about that being the best option) said:
> >
> >  While there doesn't seem to be any motivation to resolve the issues
> >  blocking the package upgrade, I'd like to point you to a package
> >  repository containing an upgrade to recent upstream release (6.2.12) -
> >
> >  http://anonscm.debian.org/gitweb/?p=collab-maint/global.git.
> >
> >  The package is also updated to follow more recent packaging standards.
> >
> >  It would be ideal if the official package got upgraded (or maybe
> >  replaced by another package), but in the meanwhile I'd like to keep
> >  the above repo in-sync with upstream releases. Please let me know if
> >  you face any issues using that version.
> >
> >
> > Anyone want to take a bet on guessing the last time that repo was
> > "in-sync with upstream releases"?
> [...]
> 
> I don't think this is reasonable to expect someone to maintain a
> non-official repository of the package while still being ignored by the
> official maintainer. See:
>
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#101

He wasn't ignored, he got an immediate explanation, which he said he
didn't understand, and that was followed by more detailed explanations
in the following days after he moved the private mail to discussion
in the BTS.

And I'm not expecting him to do anything.  He said of his own volition
a couple of months after that discussion that this is what he was going
to do.  And then just never did what he publicly volunteered to do.

And it appears he doesn't even know what he did anymore, since he
claims that he had already patched out the CGI code in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924#40

so either I'm missing something, or there's simply no evidence at
all that he ever did that in the repository he published, and no
evidence in the BTS that he actually understood what would be
involved in doing so.  All he ever said was "sure, I'll promise
that if it gets what I want".

Either way, it's quite clear that his interest in maintaining a version
of global6 vanished nearly as quickly as it was professed.


> > So if that's what we're going to do, I'd like to see some sort of
> > evidence put on the record here by the people asserting "nobody uses
> > it" to show those assertions do have some real basis in fact that's
> > stronger than a thinly veiled "I don't use it".  And some stronger
> > explanation for why we have no other practical choice to do that than
> > "I couldn't be bothered investigating bugs in other code that effect
> > me, it's easier to just break it for you instead".
> >
> > If we have that, and a good consensus on it, and nobody has any better
> > options we could opt for instead - then at least we have something to
> > point at as being a properly considered consensus decision, which I
> > don't have to worry about being dragged back here to defend because
> > somebody else doesn't like what problems your preferred option inflicts
> > upon them, if I arbitrarily pick you over them.
> >
> >
> > Until we can do that, all I can really do is what I've already been
> > doing, namely stick with the current status quo, and see what we can
> > do to address any specific individual problems that people care enough
> > about to report in some actually actionable way.
> 
> So, nothing will move on your side until I bring some proof that "nobody
> is interested in htags". Well, I won't bring any such proof either.

That was a claim _you_ made in bringing this to the TC.  Are you really
saying now that you have no basis at all for making it?


> Your mail should show the TC you don't 

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

[Vincent Bernat]

 ❦ 23 octobre 2016 17:19 +1030, Ron  :

>> > So are you asking if we should package a version that has htags
>> > removed instead of what we currently have?  Because that's the
>> > essential implication of "remove the offending CGI bit".
>> 
>> Yes. I have asked first here:
>> 
>>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#161
>> 
>> You politely said that you would rather not take this solution.
>
> Did you mean to point to some other message?  Because what you
> asked there was actually:
>
>  will you agree if someone packaged global6 without the CGI stuff
>  and use of the alternative system to let people choose between
>  global and global6 for gtags and other commands?
>
> Which is not at all the same as the question I asked above.
> I think we could pretty quickly get a consensus that creating a
> confusing mess with multiple versions and incompatible alternatives
> is not what the alternatives system was designed for, and about the
> worst possible option for how to ship something like global in Debian.

OK, so no alternative packaging.

> If you're saying yes to the question I put above, then what I'm asking
> is: what real evidence can you show to back up your assertion that
> "nobody cares about htags", and/or what compelling case can you make
> that breaking things for anyone who does use it is a lesser evil than
> the problem(s) you are experiencing, and actually a necessary evil to
> fix your problem.

I don't have any evidence.

> If ggtags is broken, that's a bug in ggtags.

ggtags relies on contemporary versions of its dependencies. Not
something that most people will call a bug. But I don't have evidence on
this either. People in the bug report don't complain just to have a new
shiny number in "global --version". They have actual problems with the
version currently in Debian.

> Without repeating what I already said above about this option, we do
> already have some evidence about how well it might be implemented in
> practice ...
>
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#176
> Punit (who you were proposing to take this over if the TC agreed with
> you about that being the best option) said:
>
>  While there doesn't seem to be any motivation to resolve the issues
>  blocking the package upgrade, I'd like to point you to a package
>  repository containing an upgrade to recent upstream release (6.2.12) -
>
>  http://anonscm.debian.org/gitweb/?p=collab-maint/global.git.
>
>  The package is also updated to follow more recent packaging standards.
>
>  It would be ideal if the official package got upgraded (or maybe
>  replaced by another package), but in the meanwhile I'd like to keep
>  the above repo in-sync with upstream releases. Please let me know if
>  you face any issues using that version.
>
>
> Anyone want to take a bet on guessing the last time that repo was
> "in-sync with upstream releases"?
[...]

I don't think this is reasonable to expect someone to maintain a
non-official repository of the package while still being ignored by the
official maintainer. See:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#101

I asked Punit to resume his work only a few days ago. I can't expect him
to have already do the work:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924#30

> So if that's what we're going to do, I'd like to see some sort of
> evidence put on the record here by the people asserting "nobody uses
> it" to show those assertions do have some real basis in fact that's
> stronger than a thinly veiled "I don't use it".  And some stronger
> explanation for why we have no other practical choice to do that than
> "I couldn't be bothered investigating bugs in other code that effect
> me, it's easier to just break it for you instead".
>
> If we have that, and a good consensus on it, and nobody has any better
> options we could opt for instead - then at least we have something to
> point at as being a properly considered consensus decision, which I
> don't have to worry about being dragged back here to defend because
> somebody else doesn't like what problems your preferred option inflicts
> upon them, if I arbitrarily pick you over them.
>
>
> Until we can do that, all I can really do is what I've already been
> doing, namely stick with the current status quo, and see what we can
> do to address any specific individual problems that people care enough
> about to report in some actually actionable way.

So, nothing will move on your side until I bring some proof that "nobody
is interested in htags". Well, I won't bring any such proof either.

Your mail should show the TC you don't intend on bringing any solution
other than the status quo.
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"


signature.asc
Description: PGP signature

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

[Ron]

On Sat, Oct 22, 2016 at 05:41:54PM +0200, Vincent Bernat wrote:
>  ❦ 22 octobre 2016 14:44 +1030, Ron  :
> 
> > It seems fair to assume that you aren't seriously asking them to
> > endorse the idea of chmod 777 as an acceptable interface for
> > distro software - but that's what "force the new version into
> > the distro one way or another" actually means.
> 
> Yes, I am not.
> 
> > So are you asking if we should package a version that has htags
> > removed instead of what we currently have?  Because that's the
> > essential implication of "remove the offending CGI bit".
> 
> Yes. I have asked first here:
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#161
> 
> You politely said that you would rather not take this solution.

Did you mean to point to some other message?  Because what you
asked there was actually:

 will you agree if someone packaged global6 without the CGI stuff
 and use of the alternative system to let people choose between
 global and global6 for gtags and other commands?

Which is not at all the same as the question I asked above.
I think we could pretty quickly get a consensus that creating a
confusing mess with multiple versions and incompatible alternatives
is not what the alternatives system was designed for, and about the
worst possible option for how to ship something like global in Debian.


If you're saying yes to the question I put above, then what I'm asking
is: what real evidence can you show to back up your assertion that
"nobody cares about htags", and/or what compelling case can you make
that breaking things for anyone who does use it is a lesser evil than
the problem(s) you are experiencing, and actually a necessary evil to
fix your problem.

Because one way or the other, _somebody's_ toys are going to be broken
here in the absence of sanity from upstream.  And if we're going to
make a consensus decision here about whose toys that should be, then
we need to be able to explain that to them in some better way than
"Vincent said 'better you than me'".

And preferably we also need to be able to explain to them what actions
they could take to try to improve the situation in their favour again
too.  And that if they don't take them (or something materially similar)
then the decision we make here will stand as the consensus for as long
as these options remain in conflict.

Otherwise we're just going to be back here again with someone asking
the -ctte to override the maintainer to revert this change.


> > Or are you asking if we should somehow fix the incompatibility
> > with "many frontends", that nobody has explicitly detailed or
> > reported yet.  Because that's a possibility too, though arguably
> > it's actually a bug in the "many frontends" and/or another fatal
> > flaw in the upstream maintenance of this software that it keeps
> > breaking compatibility by changing the meaning of existing options
> > and renaming them gratuitously.
> 
> I am using ggtags (a frontend for Emacs). I tried to quickly show how
> many options were added:
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171

A dump of --help showing different options does nothing to explain why
ggtags is actually broken.  And both you and Punit said you weren't
interested in actually investigating that when I asked what the actual
problem was.

If ggtags is broken, that's a bug in ggtags.  AFAICS, it's not even
in Debian - and it's not hard to find random software on the internet
that doesn't work with the versions of things in any particular Debian
release.  Lots of packaged software has patches to fix things like that.

That might be a bug that's easier and better to fix with a trivial patch
to global than it is to fix ggtags - but we don't know because you haven't
told us what the bug you experienced is.  And if that's your only problem
then it might be a better solution overall than "break things for other
people instead".


> Upstream doesn't break backward compatibility gratuitously,

Then I guess I must have imagined this conversation (quoted text is
my queries about him doing exactly that in changes he approached me
to review):

 From shi...@tamacom.com  Mon Jul 26 09:55:44 2010
 > As a side question to this, how will changing the current meaning of -S
 > affect existing users?  At present it takes a parameter of the path to
 > the cgi-bin dir, won't changing this break things for people?

 Yes.
 But many incompatible changes have been done up to now.
 They are written clearly as '[INCOMPATIBLE CHANGES]' in NEWS files.


 From shi...@tamacom.com  Mon Aug 02 10:55:03 2010
 > Indeed there are times when such changes are unavoidable, but we should
 > always avoid them when we can.  In this particular case I worry because
 > the -S option has been around for quite a while and is included in the
 > current stable releases of all distros that include global.  Changing
 > its meaning without it obviously failing when the old meaning was intended
 > will surprise 

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

[Vincent Bernat]

 ❦ 22 octobre 2016 14:44 +1030, Ron  :

> It seems fair to assume that you aren't seriously asking them to
> endorse the idea of chmod 777 as an acceptable interface for
> distro software - but that's what "force the new version into
> the distro one way or another" actually means.

Yes, I am not.

> So are you asking if we should package a version that has htags
> removed instead of what we currently have?  Because that's the
> essential implication of "remove the offending CGI bit".

Yes. I have asked first here:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#161

You politely said that you would rather not take this solution.

> Or are you asking if we should somehow fix the incompatibility
> with "many frontends", that nobody has explicitly detailed or
> reported yet.  Because that's a possibility too, though arguably
> it's actually a bug in the "many frontends" and/or another fatal
> flaw in the upstream maintenance of this software that it keeps
> breaking compatibility by changing the meaning of existing options
> and renaming them gratuitously.

I am using ggtags (a frontend for Emacs). I tried to quickly show how
many options were added:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#171

Upstream doesn't break backward compatibility gratuitously, they are
adding new options and frontends use them. You proposed to "fix" the
frontend to be compatible with obsolete (upstream's word) versions. Not
something that I can really find useful.

> When all you ask me is "upload global6 or else", there's not much
> I can usefully discuss except to repeat facts I've repeated many
> times before that still haven't changed.  If you can acknowledge
> the problems with that, including the ones it would make for other
> people which you don't personally care about, then we can try to
> find some consensus on what a good way forward might be ...  and
> point to that the next time someone asks "what needs to be done
> to fix this?".  But that's hard to do when people are just tugging
> hard in some direction solely on their own self interest.
>
> I want a good solution to this at least as much as anyone else does,
> but the path of least resistance is what makes a river crooked, so if
> we don't want this to end up as some sort of bug infested billabong
> spreading disease to the people who use it, then we will need some
> better answers than just "blindly package and upload a new upstream
> version" - because the minimal work needed to do just that is not the
> actual problem here.

If you want to keep the CGI stuff, a solution would be to let somebody
else create a global6 package (or yourself, as you prefer) and let this
package break/conflict/replace with global. Use of alternatives could be
a solution but this is quite more difficult as paths are not versioned.
-- 
Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Ron]

On Wed, 19 Oct 2016 16:12:51 +0100, Wookey wrote:
> Indeed. The current situation is that the existing version is so old
> that it doesn't work properly with modern code any more, but the
> maintainer has refused to do any of:
> 1) upload a new package, 

I'm not "refusing to upload a new package", I'm asserting that trading
one set of problems for a worse set of problems is not a solution to
a problem.

The crux of the problem is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#131

And I don't think it's contentious to suggest that upstream's proposed
'solution' of using chmod 777 on a privileged directory is not something
that's acceptable for a distro package.

Shigio contacted me privately in 2010, proposing this mechanism as a
replacement for the interface that he and I first worked out in 1999
to do this securely in a way that was suitable for packaged software,
and I gave him a detailed review of that, explaining why that wasn't
a suitable answer, and what we'd need to do one way or another to make
it one.  But he then simply ignored that (and later feigned ignorance
that we'd even discussed it - despite his own upstream changelog
acknowledging that we had), and made a series of incompatible changes
to do this anyway.

At around the same time, Taisuke Yamada had also expressed an interest
in this and tried to reason with him about sane ways to do this, but
his comments were similarly ignored as well.

I'd persisted with trying to find a common understanding that we could
base a real solution on, well past the point where the discussion had
become circular and repetitive, before ultimately becoming resigned to
the horrible stalemate which occurs when what you're arguing against
has devolved to a stubborn insistence that "your suggestion is not
simpler than chmod 777".

Until the discussion can move beyond that to recognise the problem,
our options were always going to be limited.


> 2) allow an upload which removes the offending CGI bit (which users
>don't really care about anyway)

If it was actually true that "users don't care about it", then it
shouldn't be a problem to get upstream to remove it.

But obviously that hasn't happened (or we wouldn't be having this
discussion), and when I last floated that option in one of the
re-runs of this, upstream outright rejected it too:
https://lists.debian.org/debian-project/2013/06/msg00174.html

The only thing he was interested in getting rid of was the option
to actually run this securely, with an audited system-wide script.
Not the parts where his own documentation and code comments say
things like "if you put this on the public internet, you lose", or
the part where he expects the CGI script must be installed in the
same tree as the rest of the generated page content.


It is true (in my opinion) that doxygen now does a much better job
of this than htags does, and that it would be no great loss (again
to me) for htags to just be killed completely if it can't be made
sane and safe.  But I think it's a big stretch to claim that is
some sort of universal consensus, and that if we removed it, then
we wouldn't just end up right back here again with someone seeking
to override the maintainer to put it back, because it is essential
functionality to them, even if the people pleading here now don't
care about it.

htags is essentially useless without the CGI support, since that
is how it accesses the global tags to provide search and indexing.
You really would be far better off just using doxygen and its
search facility that doesn't require a CGI.

But someone cares about this, because doxygen itself got a patch
to let it use htags instead of its own source browser ...  (whether
anyone actually uses that I'll leave as an exercise for someone
to research and report back to us on).

So if what you really want to do is kill htags completely, then
that's a discussion I'm willing to listen to, but it's going to
take some evidence of a genuinely stronger consensus than an
off the cuff "I don't care if we do that" - since you haven't so
far told us which bits you _do_ use and care about, so it's a bit
arbitrary to declare you, or some subset of what global currently
includes, more important than anyone else in a "rob peter to pay
paul" decision scenario.


> 3) write something to change the local behaviour to be satisfactory.

I wrote something to do this in 1999.  The fundamental problem is
itself nearly old enough to drink in pubs.  And I've maintained it for
as long as doing that was possible - but upstream has now gratuitously
broken the interfaces that we added back then (with his agreement and
collaboration and blessing) which enabled this to be done in a sane and
secure way - so the only alternative to nuking htags if upstream is
actively hostile to that now is to fork completely from upstream ...
which is essentially what has happened by sitting on the stable version
we currently have.

Yes, it sucks.  But unless somebody else can convince 

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

[Wookey]

On 2016-10-19 14:26 +0100, Ian Jackson wrote:
> Vincent Bernat writes ("Bug#841294: Overrule maintainer of "global" to 
> package a new upstream version"):
> > Ron Lee is the current maintainer and disagrees on some issues with
> > upstream and therefore don't want to update to a more recent
> > version. See bug #574947:
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947
> 
> Looking at the bug logs, Ron has failed in the one non-delegatable,
> non-negotiable task for the Debian maintainer of a package: namely, to
> make appropriate decisions with respect to the package and then to
> communicate those decisions.
> 
> Even if the decision to keep the new upstream version out of Debian is
> correct, Ron has failed to provide a coherent explanation.  He has
> failed to engage with those who were willing and ready to do the work.
> 
> I think the package would be best served by having a new maintainer.
> 
> (Sadly I don't think the TC is likely to agree with me.  Historically
> the TC has very very slow to act against maintainers who block other
> people's work and who do not communicate properly.)

Indeed. The current situation is that the existing version is so old
that it doesn't work properly with modern code any more, but the
maintainer has refused to do any of:
1) upload a new package, 
2) allow an upload which removes the offending CGI bit (which users don't 
really care
about anyway)
3) write something to change the local behaviour to be satisfactory.

Upstream has been clear that they are not going to change how it
works, but they don't care if debian omits that bit or changes it
locally, so it seems to me that a maintainer has to do one of the
above three things. 5 years of this is more than long enough to
conclude that they are not doing their job adequately, and because of
our strong maintainership culture, are preventing other people from
doing that job.

It could just be NMUed, or a global6 uploaded so at least people would
have something to work with, but asking the TC to rule seems like a
more correct way to try and unbung this situation.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

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

[Ian Jackson]

Vincent Bernat writes ("Bug#841294: Overrule maintainer of "global" to package 
a new upstream version"):
> Ron Lee is the current maintainer and disagrees on some issues with
> upstream and therefore don't want to update to a more recent
> version. See bug #574947:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947

Looking at the bug logs, Ron has failed in the one non-delegatable,
non-negotiable task for the Debian maintainer of a package: namely, to
make appropriate decisions with respect to the package and then to
communicate those decisions.

Even if the decision to keep the new upstream version out of Debian is
correct, Ron has failed to provide a coherent explanation.  He has
failed to engage with those who were willing and ready to do the work.

I think the package would be best served by having a new maintainer.

(Sadly I don't think the TC is likely to agree with me.  Historically
the TC has very very slow to act against maintainers who block other
people's work and who do not communicate properly.)

Anyway, good luck.

Ian.

-- 
Ian Jackson    These 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

[Vincent Bernat]

Package: tech-ctte
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

GNU Global is currently "freezed" in Debian at version 5.7.1 which is
8+ years old. Many improvements and bugs were fixed in more recent
versions. Also, many frontends now expect a newer versions of global
(new flags for the command-line tools) and therefore the version
currently in Debian is difficult to use.

Ron Lee is the current maintainer and disagrees on some issues with
upstream and therefore don't want to update to a more recent
version. See bug #574947:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947

The main issue seem to be around the CGI scripts. I believe that most
users don't care about those. Upstreams is OK to not have the scripts
packaged in Debian. There seems to be other issues but it is quite
unclear what they are. Bug #816924 is about the same thing but Ron
didn't participate at all:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816924

I suppose that Ron may not accept to update the package even if the
tech committee overrules him. In this case, Punit Agrawal accepts to
take over the maintainance of the package and already produced some
packages for newer versions. Those packages would remove the CGI
scripts.

Could the technical committee:

 1. Mediate this issue with Ron to get him to accept package a newer
upstream version.

 2. If unsucessful, overrule Ron on the decision to package a new
upstream version.

 3. If Ron doesn't want to package himself a new upstream version,
transfer the ownership of the package to Punit. I'll sponsor the
uploads and assist him in this task.

There are other possibilities like a different package
"global6". However, it is unsure if Ron would accept to collaborate on
this (notably with the alternative system):

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#166

"global6" could also conflict/replace global instead of using
alternatives. However, it is unclear if global6 can be considered as
replacing global. We don't know if Ron would agree to that. If he
doesn't, another possibility for the technical committee would be to
overrule him and allowing global6 to conflict/replace global.

Thanks.

- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (101, 
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJYB2qfEhxiZXJuYXRAZGViaWFuLm9yZwAKCRCVpC/oNTUl+QPX
D/9qr7DxEERMZP5Pz1tKnf5KrW8Ko94edmvYXs5Iw7qamUUlX+M+4HSCW6K4toUr
/R2SPRMmUgl85t88BgEfxCKo+j01ZIgcdCvvq3k4ZMmejXqvn/gl9YEkq7FmqS53
cBQJTUGERwHBkIBU3+gikUc77ORW+qVBg8+5gMY3lwWhQe8o+zBmRW2519AHWLVa
Pcs+Xgk2ortnxFj+En4zz7fTooRoZDD1gvGhmmXEWaQ2wjbE2g4R6mMaDQ6JByBR
QnF/AdwfDODrMD1wpW2EhpYSMwmDVCsPYneSpbNl2CMnVsA/CiPIiqpHuAkKq4cZ
GgRhdGY+lCFzkXeI759gCY6gmMvsXLRyTBYSnUwHwRiSgHxyR9TlEaFPzG8k8wz7
b88XcKMrQek7uWVhlCoKm1bdaoiHFcGjwKc+cjTnGmKHVcpiXQuZI8mTv9B34nsJ
2LHcE9GxU3FOOkWmOLBtI4tkfJlmXxGdUzD/8a4kIZibpbIvC/qrCyaQQsp33/U1
UdXJOqsaB7ghGKlsHbw+ZGK8a9lqaxqtR3Tm+Wu/kB6/h+zZ9miRUfRrAygIMgJd
aRKkNZ8FCC6VnkBdn2WKGoxrRo2ZohCNkZ0Ls7ed9RenwXU1eJvzvTrrWUpwyL1K
wrSB5i0RRLkLQzUB/fmKbaPjU2OzuH4qsc1xLU9AqRfgcw==
=lWow
-END PGP SIGNATURE-