[1953] in athena10
Re: Athena delete
daemon@ATHENA.MIT.EDU (Jonathan Kamens)
Sun Mar 29 20:34:49 2009
X-Barracuda-Envelope-From: jik@kamens.brookline.ma.us
Message-ID: <49D01378.8040102@kamens.brookline.ma.us>
Date: Sun, 29 Mar 2009 20:34:00 -0400
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
MIME-Version: 1.0
To: Anders Kaseorg <andersk@MIT.EDU>
CC: belg4mit@pthbb.org, debathena@MIT.EDU
In-Reply-To: <alpine.DEB.2.00.0903291733180.6942@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 03/29/2009 06:27 PM, Anders Kaseorg wrote:
> Thanks for the patches; we would be happy to include them. Are you
> willing to release them under the same license as the current software,
> the MIT license (mit-copying.h)?
>
Yes, of course.
> After some discussion,
It would be nice if you had included me in that discussion.
> we decided that we cannot realistically support
> multiple packaging systems from the Athena source tree. Since Athena
> development is centered around Debian packaging, providing RPM packaging
> for a single package would imply a maintenance promise that we aren’t in a
> position to make.
I think this concern is unfounded.
Surely a group of people who are smart enough to figure out how to build
a complete Athena distribution are smart enough to check a
"README-rpm.txt" file in one of its directories which says something
like, "The file debathena-delete.spec and the contents of the 'rpm'
directory have been contributed by a third party to assist those who
wish to distribute debathena-delete in RPM form. These files are not
supported by Debathena. If you have any questions or concerns about
them, please contact Jonathan Kamens <jik@alum.mit.edu>."
I confess that I find your objections hard to understand unless what's
really going on here is a veiled APT vs. RPM religious war. I have no
desire to be involved in such a war; I merely want to help people who
want to use the software to do so.
That's one of SIPB's missions, isn't it? At least, it was when I was there.
> Tools like git-svn or svk would let you maintain a Red
> Hat package in an external tree, which doesn’t need additional support
> from our end.
>
I think it is highly suboptimal to expect me to spend time and effort
setting up a publicly accessible repository on a server somewhere, just
to make RPM distribution files publicly available, when you can do the
same thing essentially for free merely by checking them into your tree.
I also think it is suboptimal to fragment source for the same package
all over the Internet which could just as easily be consolidated in a
single location.
Here I am, the guy who wrote the code in question twenty years ago,
stepping up and essentially volunteering to maintain it. In exchange,
all I'm asking is for you to check a few files into your source tree
that your build won't even notice. Your response, frankly, is foolish.
Jonathan Kamens
