Hi OdyX,

On Wed, Nov 16, 2016 at 03:23:47PM +0100, Didier 'OdyX' Raboud wrote:
> Hi there,
> 
> I've been mostly VAC, and only now found enough time to properly read 
> through this bug log. In the interest of transparency and to help the TC 
> reach a consensus (also through understanding what the other members' 
> understanding, ideas and positions are), here comes my current 
> understanding of the problem at hand.
> 
> As preamble, I will upfront state that I have _not_ looked in the precise 
> details of the so-called 'htags' functionality, as, the rest will show, my 
> current viewpoint on the problem is that it doesn't matter.

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.

But since people have actually tried the latter, and it's not a "simple
regression", but rather upstream rejecting such discussion and then
actively removing features needed to implement it sanely in a distro
package context - it seems that only leaves the former ...


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.

If anything, it probably has more in common with the cdrtools situation
where upstream actively opposed making it suitable for distro use, while
insisting we accept those changes ...  and we're split between some users
which want what has been crippled, and some which need what appears to be
just a few small changes which have been made upstream since.

And all of those people are supposedly software developers (as there's
not a lot of use for this package for people who aren't).


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
to solve their problem by penalising the other group, who so far wasn't
complaining, without any notice or real opportunity to contribute to
improving that for themselves if they end up on the losing side of this.

Which is why I suggested what I proposed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#155
better summarised by Tollef in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#245

That gives the people who care about htags time to (re)act, and as soon
as the backports suite for Stretch opens, it means we get the essential
essence of what Phil had suggested for free too.

For Stretch people would be able to pick what they want in the same way
as he suggested, without triggering the concerns I expressed about
forking this in a single release and juggling about with which one owns
'global' as an unqualified name, and having to decide when to 'unfork'
it again, and face the fallout that might bring on.


How is that worse than telling the people who want htags, who do have
a history of sending thought out patches, that "your only option is to
create your own packages locally if you want to use this in Stretch"?

Maybe I missed something in what you're suggesting, but I don't see
how you suggest we defuse that from blowing up in our faces through
some reasonable and fair and justifiable action.  Because their
complaint wouldn't really be substantively any different from what
the people who don't use htags are currently making.

"You're on the wrong side of a version number" isn't a very compelling
or satisfying or technically astute rationale, if that's all it boils
down to.  I'd like to have something a bit more substantial and fair
than that to offer the people who'd get burned without notice by this.


  Cheers,
  Ron

Reply via email to