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:
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:
> ꀠ㗎mm. 啱 still don't quite understand how the long-term release would
> ꀠ烀ork 餸o we still do twice-a-year stable releases, but use the same
> ꀠ漤kgsrc as -current for them? 嘢r do we do away with the 6-month schedule
> ꀠ汢ntirely?
>
> ꀠ咗e haven't been very good at MFCing stuff to stable. 糍here hasn't been
> ꀠ乸 huge demand for it, either. 嗰ost people use -current. 脷ut at the same
> ꀠ濳ime the reason why most people use -current is because -current often
> ꀠ烀inds up with all the new and cool stuff which -stable will never get.
>
> ꀠꀭ-
>
> ꀠ啱f I read this right, let me rephrase it and you tell me if I'm on
> ꀠ濳he right track: 咗hat we need to do is divorce the builds of the
> ꀠ漤kgsrc quarterlies from the dragonfly-release versioning. 糍hat is, we
> ꀠ烀ould build and maintain a certain number of pkgsrc quarterlies but do
> ꀠ湶t all for some designated release (up to 3 years old), and run THOSE
> ꀠ漤ackages not only on that designated release but also on all the releases
> ꀠ湶nbetween AND ALSO ON -CURRENT.
>
> ꀠ糍hat is, we would not build the binary packages for -current on -current,
> ꀠ烀e would build particular quarterlies but they would ALL be built on some
> ꀠ澵pecific prior release and they would be *run* on everything, including
> ꀠꀭcurrent.
>
> ꀠ脷y building packages on a designated prior release but running on
> ꀠꀭcurrent (as most of us do), any incompatibilities would become self
> ꀠ汢vident and we would be able to fix them in -current to restore
> ꀠ氲ompatibility.
>
> ꀠ糍he only issue I see with this that might not be easily fixed would
> ꀠ毪e compiler incompatibilities.
>
> ꀠ啱s that what you are saying? 嚒tick with our 6-month release but divorce
> ꀠ乸ll pkgsrc builds from DragonFly versioning entirely?
>
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀭMatt
>
>
討論串 (同標題文章)
完整討論串 (本文為第 6 之 16 篇)：