Re: DragonFly versioning plan

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

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:

http://netsplit.com/2011/09/08/new-ubuntu-release-process/

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
source.

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
<dillon@apollo.backplane.com> wrote:
>    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
>    entirely?
>
>    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
>    -current.
>
>    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
>    compatibility.
>
>    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?
>
>                                                -Matt
>
>