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

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



On 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 - and assume that you have no other life
but to hit refresh continually on this mailbox, and that you saw the
original request the instant that it came in, and that you instantly
dropped everything to make it your number 1 priority, and that you
can type infinitely fast, and that your reply wasn't greylisted by
the BTS mailserver ...

Then according to the timestamps of the messages received, you spent
a grand total of 42 minutes to read and understand the details of the
original request.  To read and understand the ~50 posts to the BTS
about it.  To read and understand the 15 odd messages in the thread
on -project, to examine all the relevant versions of the software to
get some understanding of what it does and the issues involved, to
form some considered opinion on all that, and to think of something
snarky and derogatory and slanderous, and plainly and simply wrong
in almost every respect to write, and then to rush that out as a
summary and final judgement in the hope to get in first and (maybe)
influence subsequent opinion on the matter ...

Seems legit.


But since it seems fairly safe to assume that at least one of those
assumptions is not entirely correct ...  Remind me why it is that
anyone should give any credence at all to your angry, ill-considered,
malicious, thoughtless, self-contradictory, knee-jerk ramblings here?

Especially when you are telling people that someone like Tollef - who
is genuinely attempting to understand the issues here, and is genuinely
concerned about achieving the best result possible for everyone - is
wrongheaded in thinking that this is how we could best deal with it.


I'll try to find all the time that is needed to help anyone who does
genuinely want to help improve this.  But if you have nothing at all
to offer in the way of actual technical advice, and just want to use
this as a forum to seem self-important and disparage people like me -
then I don't have the spare time to entertain your senile crap.

There's a release freeze looming and all of us have important things
to do.  So if you don't have anything actually useful to contribute,
then please just go away and leave this to the adults to discuss in
a mature and sensible fashion.

  Thank you.
  Ron


Reply to: