Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Aug 1997 13:59:56 +0200 (CEST)
From:      torstenb@onizuka.tb.9715.org (Torsten Blum)
To:        jkh@time.cdrom.com (Jordan K. Hubbard)
Cc:        asami@freebsd.org, current@freebsd.org
Subject:   Re: ports-current/packages-current discontinued
Message-ID:  <m0wvLno-0006FEC@onizuka.tb.9715.org>
In-Reply-To: <2847.870634281@time.cdrom.com> from "Jordan K. Hubbard" at "Aug 3, 97 11:51:21 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard wrote:

> FWIW, I don't think that supporting ports in -current is a long term
> strategy for success anyway.  Even if TCL had never made it into the
> tree, I can easily envision multiple other scenarios which would
> result in serious headaches for anyone trying to track a moving target
[...]
> Our most important
> branch of development from the customer POV is not -current, it's the
> current release branch.  It's this branch which most needs packages
> built for it, it's this branch which most people will install off of
> CD and, if you look at the download stats on ftp.freebsd.org and other
> sites, it's the most popular download target.

People, let's do not forget the purpose for -current: It will become the
"next" release (*1).
When such a release is done, all ports have to be "ported" to the new
release. Even if you want to do that (and I'm sure that none of the porters
wants that, including Satoshi): You can never test all features of all ports
in a short time and if you try to do that, you'll forget something.
When a new release comes out Satoshi is more than busy building all packages,
but checking if it really works with the upcoming release is impossible.

And don't forget that many of the more active porters run -current.

> The folks who run
> -current are another breed, and I think it's also safe to say that
> they're the most capable of building their own packages and/or
> adapting ports to their use (and if they're not so capable, they
> probably should not be running -current in the first place).

Well, most of us who run -current are capable of building their own
ports and packages. Not to mention that many of us do ports since we
have this nice mechanism .

But, building own ports/packages is a matter of time and I since I don't
have much time I try to save as much as I can.

> Trying to match -current's rate of change in
> the ports collection is nothing more than a recipe for insanity and
> premature death among our ports team and I also think it's a waste of
> their time and abilities.

Well, as I said before, you can not change all ports to the "changes 
between -current and the upcoming release". That is what I call insane.

> Up until now we've had it exactly
> *backwards* in our policy of supporting -current and dropping support
> for the release branch quickly (something which has created a lot of
> ill-will in the user base, I might add, as reading USENET will show)
> and when I read Satoshi's announcement that he was dropping support
> for -current, I felt no dismay at all.  I've always regarding this as
> inevitable, and having more attention paid to our release branch as a
> result can only be a good thing for the majority of our user base.

*1:
I think one reason for the troubles is that we started with the -stable
branch some time ago for "bug fixes" only. Then we started to add new
features from -current (login classes and other things come to mind).
The problem I see here is that we do not have the resources (mostly
manpower) to do that.
Don't get me wrong, I think -stable is a good idea, but it consumes
lots of resources.

We only have two choices IMHO:
1) using the -stable branch only for "bugfix releases" (or call it "patch
   kit", "service pack" etc)
2) get (hire?) more manpower to maintain the "-stable" branch and the
   ports tree.

I know this is likely to cause a "flame war", but ignoring the problem
does not solve it...

 -tb



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0wvLno-0006FEC>