Re: INN packages
In article <[🔎] 20000117200446.D1032@wonderland.linux.it> you wrote:
> My suggestion for a compromise is to package inn 2.x as inn2 and if
> the release manager accepts that, put again the old 1.7.x package
> in potato.
> Bdale, would you do that?
Maybe. I thought long and hard about doing it that way, and I am *not*
convinced that Debian will be a better distribution with more than one version
of INN present.
If we were to do this, someone else would need to adopt the 1.7.2 packages,
as I have no interest in maintaining two versions of INN, and I'm moving
my servers to the 2.2.2 packages. Also, note that there were a number of
fairly serious and release-critical bugs against the 1.7.2 packages. If I
were the release manager, I would insist that they be fixed before I put
those packages into potato.
There is also the question of the innfeed package. Since innfeed is included
in the inn 2.2.2 package, I intend to request that the discreet innfeed
packages (which I also maintain) be removed from potato. If you really want
to put inn 1.7.2 back into the distribution, this will need to be addressed
too. Since there is no huge rush, I won't request the removal quite yet.
> There is no point in packaging INN 2.x as inn, an automatic upgrade
> path is not possible anyway.
I don't completely agree with your logic. The ability to do a completely
automatic upgrade has never been a first-order decision point for forking
a package based on version that I am aware of. It would certainly have been
easier for me to just orphan the 1.X packages, build new 2.X packages under
different package names, and avoid this whole issue. I have never felt that
was in the best interests of the users of the Debian INN package, which is
why I did not do it.
If there were some easy way to have the primary inn packages for potato be
the 2.2.2 packages, and to continue to have 1.7.2 available as inn1 or
something like that, I'd be somewhat happier... but our packaging system
would not handle this idea very gracefully.
> I think the 1.7 without the insync patch can support many more users
> than 20.
Absolutely. I am even aware of one moderately-patched 1.5.1 server on an
HP 9000/735 HP-UX system with well-optimized disk layout that is still happily
serving as a significant mostly-transport-but-with-some-readers server for a
major corporation. I think both of you have been fairly harsh in your
comments about versions other than 2.3. When properly tuned, they are quite
capable.
Alexander implied with his comments that I'm somehow not very knowledgeable
about news servers or the state of INN development. Without rattling off my
news pedigree, suffice to say that I have maintained at least one news server
continuously since 1985. I read "all the right lists and groups", and I think
I know quite well the status of the various INN versions.
The current stable and supported release of INN is 2.2.2. The 1.7.2 version
is obsolete and should not necessarily be expected to be included in future
security patch releases, etc. The 1.X insync patch and others that people
talk about are not mainstream, despite how useful they might be. The 2.3
version is still in very active development, and it is completely unclear
when it might be released... though I suspect it will be well after potato
ships. And regardless of what their motivations might be, I have had a fairly
steady stream of email over the past months from Debian users asking when we
would migrate from 1.X to 2.X.
Given all of this, I chose to move from 1.7.2 to 2.2.2 for potato, and intend
to continue following the 2.3 development with the expectation that it might
be the right choice for our next release (woody). You are certainly free to
disagree with my reasoning, and I'm willing to discuss alternatives. However,
please understand that as the maintainer of the Debian INN packages since May
1999, I have thought about this quite a bit, and have planned for months to
ship 2.X as the INN version in potato. The appearance of INN 2.2.2 packages
for potato was not a quick decision on my part, and was not made arbitrarily.
Bdale
Reply to: