Re: DragonFly versioning plan

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

On Mon, Sep 12, 2011 at 3:17 AM, Francois Tigeot <ftigeot@wolfpond.org> wrote:

> It is also perfectly possible to build pkgsrc binaries with the tools of
> the previous quaterly release. pkg_install from 2011Q1 can be used to create
> 2011Q2 packages, thereby removing the binary compatibility problem entirely.

It is possible to build pkgsrc binaries with the previous release's
tools.  You can't install binaries built with that newer release's
pkg_install using the older pkg_install.  So if I put a newer set of
binaries on avalon, pkg_radd won't work.

> 3 years is a long time; I'm not sure the DragonFly project has the resources
> to maintain a release for so long.
> Besides, long term releases (Ubuntu and Debian come to mind) have a tendency
> to rapidly become obsolete on the driver side and not work with newer
> hardware.

3 years is a long time; it's an arbitrary time period.  I don't think
it's that much more labor than now, as we are in theory always
supporting the release - which changes about every 6 months.  It's a
longer timeframe I'm suggesting, but still no more than one release.

Yeah, those long term releases become obsolete in terms of driver
support - but not for the systems they're already installed on.

> What about security updates ? At one time, we'll have 3-years old packages
> full of security holes and the long-term release will also be broken out of
> the box, albeit in a different way...
>
>> - We point people at DragonFly-current for everything else.  That way,
>> everyone's generally on the same version unless they explicitly opted
>> for something else, and we don't have to say "well, install a
>> completely new version", and we have more people trying new features.
>
> Or not; without the right mix of stability _and_ up-to-date features, many
> users could just abandon DragonFly entirely.
> I, for one would not install an experimental version on production servers,
> and I would not buy refurbished hardware to run a 3-years old one either.

That's why we would need to MFC.  The need for MFC is present with
6-month releases too.

The other side of that problem is: I don't want to install an
operating system I'm going to have to upgrade within 6 months on a
production server.

> An operating system is different from a website; you can't force people to
> upgrade according to your schedule.

If we don't want to force people to upgrade, a long term release would
certainly help.

> I don't see any obvious benefit to what you're proposing either. The current
> release cycle (2 releases per year) is not broken and is IMHO a good
> compromise.
>
> Pkgsrc binary compatibility is not a real problem (what's wrong with removing
> the previous binary packages before installing new ones ?) and can be fixed by
> building packages in a slightly different way or installing from source.
>
> Why fix DragonFly ?

What's wrong with removing previous binary packages before installing
new ones?  The fact that you're removing all the existing packages
before you can install new ones.

You've been in IRC; you've seen it.  Someone comes in and says "I want
to install DragonFly/update my system.  What do I do?"  We tell them
to install DragonFly, but they have to go current to get the driver
support anyway.  What they then need in either case is to install or
update pkgsrc, and for that we tell them "Don't use bmake update
because if it fails you won't have anything installed at all.  Use
pkgin, but if something isn't there, you need to build from source,
but make sure you have the right quarterly release installed in
/usr/pkgsrc, so you can use the Makefile in /usr, but you'll have to
get the right branch set by hand.  You can pkg_radd it but it won't
always be the most recent quarterly release, so you may have to switch
to all building from source to get it except in a month the next
release will be out.  Just build from source, so that you have to wait
maybe an hour to find out if you have success or not"

We (especially me) are burning a lot of time, CPU, and disk space
building binary packages, and the process resets every 6 months, where
we go back to zero and rebuild.  I'd much rather continuously build
for a platform that isn't changing, and for a platform that's
following a constant change (pkgsrc-current) rather than 3-month
changes from pkgsrc quarterlies mixed in with 6-month changes for
DragonFly, that aren't on matching timetables.

Here's an example going on right now.  pkgsrc-2011Q1 is available as
binaries now.  I built pkgsrc-2011Q2, but it can't be automatically
installed by pkg_install because of the aforementioned restriction.
(though I hope that will be fixed/mitigated soon.)  pkgsrc-2011Q3
should be out by the end of the month, so I can restart the building
process for that, but it takes weeks, and according to our schedule,
DragonFly 2.12 is due soon, so the build would intersect with the new
release, so I can either wait for it (so packages in binary form get
farther out of date) or build on 2.10 and then again on 2.12, burning
a lot of resources and creating a few gig of unused packages, or 2.12
is delayed farther to give time for the build, so we're off the
6-month schedule at that point anyway.