DragonFly kernel List (threaded) for 2011-09
Re: DragonFly versioning plan
I'm saying the inverse.
- We have a long term release of DragonFly that stays for some time >1
year, and a current version, built daily.
- The long term release gets quarterly pkgsrc builds, and the current
version of DragonFly gets pkgsrc-current.
- People who want stable, get _stable_. People who want new features,
get new features.
We already sorta do this; I'm saying let's just do it more so.
We have remained astonishingly stable in -current for years now, so we
should take advantage of that fact. I think the division in time
between release and current should be greater; this is happening with
other open source projects these days. (see Firefox, Chrome, for
faster rolling releases; see Debian for longer major releases plus
Debian unstable for testing.) Samuel, in IRC, pointed at this link
for a somewhat similar thing suggested for Ubuntu:
Our current plan has us releasing every 6 months, which is fine, but
it's not gaining us anything. If we're going to have a 6-month stable
and current, and current is generally working as well as stable but
has newer features and packages, why put the effort into having that
6-month stable package?
If someone says "I want the newest things", make sure that person gets
it: DragonFly-current. If they say "I need to have a stable
platform", make sure that person really gets it: a long-term release.
I think the stable releases we have now at 6 months aren't really
delivering either of those to their fullest.
I'd like to have a version of DragonFly that someone can install and
know will work for some time, in production. I have machines at work
that specifically have 'long-term support' versions of the operating
system, and long-term support versions of the open source applications
on them, because I can't rebuild, test, and deploy every few months.
I don't want to spend time treading water because I'm using open
My suggestion about pkgsrc on a long-term version of DragonFly was
because pkg_install refuses to install packages built with a newer
version of pkg_install. Even though we can automagically make binary
installs go to new quarterly releases by adjusting the "stable" link
on avalon to point to a new set, the packages won't install until you
manually update pkg_install. This may change - I'm bugging pkgsrc
people about it.
Assuming it does change, it just means we do quarterly pkgsrc builds
for the long-term release as normal and binary upgrades will work,
even when changing between quarterly pkgsrc releases.
It also means my suggestion of having to stick to an out-of-date
quarterly release doesn't apply.
I think our relative lack of MFCing comes in part from the fact that
the next release is always a few months away. Having it be more
clearly distant may help increase pressure to update. It can't make
us worse at it, at least.
On Mon, Sep 12, 2011 at 1:39 AM, Matthew Dillon
> Hmm. I still don't quite understand how the long-term release would
> work Do we still do twice-a-year stable releases, but use the same
> pkgsrc as -current for them? Or do we do away with the 6-month schedule
> We haven't been very good at MFCing stuff to stable. There hasn't been
> a huge demand for it, either. Most people use -current. But at the same
> time the reason why most people use -current is because -current often
> winds up with all the new and cool stuff which -stable will never get.
> If I read this right, let me rephrase it and you tell me if I'm on
> the right track: What we need to do is divorce the builds of the
> pkgsrc quarterlies from the dragonfly-release versioning. That is, we
> would build and maintain a certain number of pkgsrc quarterlies but do
> it all for some designated release (up to 3 years old), and run THOSE
> packages not only on that designated release but also on all the releases
> inbetween AND ALSO ON -CURRENT.
> That is, we would not build the binary packages for -current on -current,
> we would build particular quarterlies but they would ALL be built on some
> specific prior release and they would be *run* on everything, including
> By building packages on a designated prior release but running on
> -current (as most of us do), any incompatibilities would become self
> evident and we would be able to fix them in -current to restore
> The only issue I see with this that might not be easily fixed would
> be compiler incompatibilities.
> Is that what you are saying? Stick with our 6-month release but divorce
> all pkgsrc builds from DragonFly versioning entirely?