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 <[email protected]> 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 > >
