Ron <ron@debian.org> writes:
...
> I'm not insisting that's what we should do. But it's certainly an
> option, and it dodges the bullet of having to say "Sucks to be you"
> without any notice at all. And it doesn't take anything away from
> the people who want "new upstream or bust" for Stretch, because it
> can still be available to them in backports.
Perhaps you'd be kind enough to either confirm or correct my perceptions
of the current situation:
Version 6 includes a CGI script that one is expected to install in a
manner so hopelessly insecure that we'd not accept it in Debian.
However, it is possible to generate static content that achieves the
same aims, but at the cost of approximately doubling the disk usage,
and presumably also requiring more time to generate.
Also, for people that want personal access to htags there is a
htags-server command that brings up a dedicated server to run the CGI
as the invoking user, by default bound to a localhost port.
Version 6 fixes some bugs that are still present in your version 5
package and/or provides features that are missing, but bug reports of
sufficient quality to allow you to fix/backport to v5 are lacking.
Is that about right?
Are there any other regressions that you are aware of in v6?
Your suggestion, as I understand it, is that v6 should hit unstable
after stretch's release, and that people who are currently complaining
about bugs/missing-features in v5 (or are overly focused on numbers) can
then grab v6 out of stretch-backports.
Could you consider the relative merits of instead putting v6 into
stretch now, and dealing with the people that are currently clinging to
v5 by pointing out that:
0) there are now other alternatives to htags that might suit them better.
1) htags-server lets them run the CGI for local access.
2) htags can generate static content, and thus safely provide general
access while avoiding the need for a CGI
3) If there is anyone that cannot do either for some reason, they can
install global v5 from jessie, pin it to avoid upgrades, and report
the reasons why they had to do this to the BTS.
Have I missed some vital aspect of this?
Is there a compelling reason to favour the theoretical users that might
want to stick with v5 over the actual users that we've been hearing ask
for v6?
If the TC were to achieve consensus that v6 should be in stretch, will
it be sufficient for us to inform you of that in order to make it so?
I gather from what you just wrote that it would be sufficient.
If however you are likely to insist on resolutions to override the
maintainer, or transfer the maintainership, I think you ought to be
up-front about that in order to avoid any accusations of intentional
time-wasting later on.
If you can keep your answers brief, you'll earn my gratitude.
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
Attachment:
signature.asc
Description: PGP signature