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

Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system

On Thu, Feb 03, 2005 at 11:31:55AM +1100, Matthew Palmer wrote:
> On Wed, Feb 02, 2005 at 02:38:10PM +0100, Florian Weimer wrote:
> > * Matthew Palmer:

> > > On Tue, Feb 01, 2005 at 06:27:30PM +0100, Florian Weimer wrote:
> > >> * Lars Wirzenius:

> > >> > ti, 2005-02-01 kello 15:25 +0000, Stephen Quinney kirjoitti:
> > >> >>  This is the 3.4 series of RT, it can be installed alongside the 3.0
> > >> >>  and 3.2 series without any problems. This release is a big
> > >> >>  improvement over previous versions and features many new features,
> > >> >>  substantial performance improvements and a significant cleanup and
> > >> >>  restructuring of the codebase.

> > >> > What is the a reason every version series of Request Tracker needs to be
> > >> > packaged, instead of having a single request-tracker package that gets
> > >> > updated with newer versions?

> > >> Request Tracker is a development framework for trouble ticket systems.
> > >> Users are encouraged to add new code to its (Perl) packages, and
> > >> there's an overlay mechanism to support this.

> > >> Unfortunately, this makes updates non-trivial, at least sometimes.

> > > So you do a bit of testing before madly apt-get dist-upgrading your
> > > production servers.  What a concept.

I agree with this absolutely. Anything in production should be being
watched carefully when apt-get upgrading if it's not running stable.
If it is, you only have to watch it, not watch it carefully. ^_^

However, I think the sentiment is misplaced in this discussion. I
also think the next paragraph is equally misplaced. There's good
reasons for multiple libraries, and we have sonames to account for
that. There's _different_ (albeit parallellable) reasons for this
discussion, and here the waters are just being muddied.

> > As Andrew noted, we already do similar things for library packages.
> > There's a growing trend to provide different version which can be
> > installed in parallel for other infrastructure packages, too (IIRC,
> > PostgreSQL is heading in this direction, too).

> > As a user, I think this is very convenient.  The ability to switch
> > back to a known-to-work version by tweaking a few configuration files
> > is reassuring, even if you've tested the new software version on an
> > indepedent machine.

I have to say, I prefer the ability to parallel-deploy, so I can give
certain users (the ones who don't panic and start deleting things when
they get an error message) access to newer systems for acceptance
testing against production data.

> So archive bloat is not a problem for you, and "apt-get dist-upgrade" not
> actually providing upgrades to the latest versions of everything is
> perfectly fine?  Ability to switch back is provided by backups and planning,
> not by having a million versions of a package in the archive.  If you really
> want this, work out a way of installing multiple versions of the same
> package through path redirection.

I'd like apt-get dist-upgrade to fetch me the latest version of
something (in the Debian distribution I'm using, obviously) that's
either not going to break things, or will break things and has a
NEWS.Debian file that apt-listchanges can beat me with.

We could after all extend your arguement against multiple versions
of things in the archive to the Debian distribution itself. Instead,
I'm going to extend the argument for multiple Debian distributions
to request-tracker, since it is a large piece of software which is
highly locally-modified by many of its users, and which an automated
upgrade between releases is difficult.

I'm not saying this is true for all applications, or even most. For
FreeRADIUS, I'm currently in two minds as to whether I should put a
freeradius version into experimental or just move straight to 1.1.0
when it is released, and hope for the best. I will probably do the
latter, since we go to great lengths to be sure the upgrade is easy.

However, things like apache where configuration and APIs have changed
significantly are obviously easy candidates for this sort of thing. I
can't see _any_ circumstance I'd want apt-get -u dist-upgrade to replace
Apache 1 with Apache 2.

I think the line is best guided (only guided, not dictated) by the
upstream attitude. Is the older version deprecated/unsupported, or
is it "stable" (as compared to development) and actively supported
with bugfixes and security updates in parallel to the new version.
That should give a guide as to the usage patterns of the users of
that software, if nothing else.

I'm not gonna get stuck into archive-bloat. I consider it a risk
of unstable, and basically ignorable in stable (how often are you
dist-upgrading a stable machine?) but I was spoilt by living on
campus with an on-campus mirror for my unstable machines to beat
upon, so I can't say I've suffered at all from it.

> Libraries are the way they are because they are the way they are.  If they
> weren't the way they are they wouldn't be the way they are.  If RT's a
> library, start defining API compatibility and package it like a library --
> lib* prefix and all, so people know what they're getting into.

It's not a library, it's a large data-driven application, and the
framework that data's structured into changes between releases, making
it hard to autoupdate the data to match the new library. I think
bringing libraries into the dicussion was another poster's... straw man?
(I'm not sure that's the right logical fallacy) and doesn't help at all.

I will say, I'm not _100%_ convinced that request-tracker needs to have
3.4 and 3.2 packages, but I am certainly more convinced of that than I
am convinced that there's no need for seperate packages. _My_ usage of
it is probably one that could survive a dist-upgrade to 3.4, but I'm
only one user who hasn't bothered customising it much.

Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.

Attachment: signature.asc
Description: Digital signature

Reply to: