Re: Thwarting Policy via BTS
Thomas Quinot <thomas@cuivre.fr.eu.org> writes:
> > later you uploaded a NMU, without ever giving me a chance to confirm
> > that the problem existed, that your suggested fix is solves the
> > problem, and that said fix does not cause bugs elsewhere. You also
>
> You can rest assured that I had confirmed the existence of the problem
> before even posting the bug to the BTS. After applying the proposed
> fix to my local package, I did some testing, and also checked the upstream
> archive, which has had the very same fix for the very same bug for
> two weeks.
To put it in a nutshell: This is irrelevant handwaving. Barring
exceptional circumstances (ie, a root-compromising security hole), you
do NOT NMU a package after giving the maintainer less than 30 minutes
to analyze the issue and respond.
The point is: this is not your package. You have violated the entire
maintainer structure in Debian by treating it as if it is yours. Not
to sound greedy or anything, but the package is MINE. This means that
the buck stops with me. If you break the package horribly, I have to
clean it up. (Same thing if I break the package horribly.) I am also
the first line of defense our users have against bugs, because when
new releases come out, I test them before releasing them into Debian
*AND* I test patches sent before releasing THEM into Debian. This is
the trust that our users have in me, and it is my responsibility, and
frankly your actions can do nothing but cause trouble for me. To be
completely blunt, you do not know as much about this package (or
probably most any package) as the maintainer does, and "fixes" you or
others may make could have problems.
In this particular instance, you have demonstrated a fundamental lack
of understanding of even the most basic commands involved in the code
that you modified, let alone any significant knowledge of the design
of the code.
Furthermore, you are apparently unaware of some basic development
principles, to wit: the mere fact that a change has occured in a
development version does NOT automatically mean that said change can
be applied to the production version without dire consequences!
> This is not the way I proceeded. I do not usually post a bug to the
> BTS unless I have done at least some assessment of the bug. In this
> case, I went through all the process of finding out the cause of the
> problem, devising a solution and testing it before submitting the
> bug to the BTS (which is the reason why the report came with a working
> patch). As you rightfully observe, this process has taken far more than
> 24 minutes.
In which case, why deny me the opportunity to review what you have
done? As maintainer, this is my duty, responsibility, and RIGHT. If
I am negligent in testing a package, people (rightly) blame me. If
you are negligent in testing your NMU, I still have to deal with it
and I still have to fix it. IT IS NOT YOUR PACKAGE.
>
> > Furthermore, this bug was not by any stretch of the imagination grave.
>
> I am afraid I have to disagree here. I consider that a mailing list
> management system where one cannot administer a list is unuseable or
> mostly so. Several mailing lists are hosted at my site where email
> is the only medium people use for list administration. Most list
> administrators here are not even allowed to log in to the machine
> that runs listar.
You are not even close to being correct. This bug does not prevent
administration. I have been administering my own lists with this very
version of Listar since it was first released into Debian. I guess I
should say RTFM at this point.
>
> In this situation, which I suppose is common, being unable to administer
> mailing lists through email with the 'admin' command therefore makes
> the package 'unuseable or mostly so'.
OK, if you don't want to RTFM, the relevant command is admin2. Which
was not broken. HAD YOU FOLLOWED PROCEDURES, I would have had a
chance to tell you this, and would not be angered at having to do so.
However, when you modify code in a package you do not maintain (or one
you do maintain, for that matter), you are expected to have the
requisite knowledge to do so properly.
> I am sorry if you consider this NMU as inappropriate. I hope this
> mail will address at least part of your concerns.
I'm sorry, it has only deepened them. You have shown that you don't
know how to interact with the server as a user (which is not a
liability except in this case) and yet you proceed to modify and NMU
the package without my prior knowledge or consent; this modification
based upon your (lack of) knowledge. I consider it extremely
fortunate that you did not happen across some other minor
inconvenience, decide to backport the change from CVS, and thus cause
severe problems for everyone running Listar.
You might note that recently Bash was broken but just such a NMU.
This caused all sorts of problems, including breaking other packages
in the system. There is a reason why NMUs are supposed to be rare,
and you are ignoring it, endangering the Project and its packages in
the process.
You also have yet to justify why you gave me only 24 minutes to
respond.
--
John Goerzen Linux, Unix consulting & programming jgoerzen@complete.org |
Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org |
----------------------------------------------------------------------------+
The 27,036,197th prime number is 513,652,507.
Reply to: