On Sat, 2006-05-27 at 13:01 +0300, Mikhail Kolesnik wrote:
On Sat, 27 May 2006 11:28:13 +0200 Mark Rosenstand <mark@borkware.net> wrote:
On Sat, 2006-05-27 at 10:50 +0300, Mikhail Kolesnik wrote:
Seems me is going to make himself a fool once again...
On Sat, 27 May 2006 01:17:11 +0200 Mark Rosenstand <mark@borkware.net> wrote:
Are crux users supposed to be 'bleeding-edgers'?
Not according to the handbook, which states "the latest stable packages" - although for critical core components it makes sense to be a bit more conservative, e.g. leave out x.x.0 versions of the C library and compiler.
Handbook can not cover the update frequency & toolchain details... In real world we can't just replace all the system staff with "the latest stable packages".
Works for me (and I consider my world pretty real.)
As for me, it also would be great too have official releases less frequently, say one in 14-16 months (and updating non-toolchain stuff more frequently).
Or even better: core could be branched, while opt is a moving target. People could then choose to stick to the release version of core (or a security-fixes-only branch of said release) while those wanting to help make the next release top-notch could follow trunk.
Both camps would run the latest and greatest opt ports. This is much similar to the FreeBSD 'src' and 'ports' modules.
core != toolchain, and many ports from core might be updated fairly easy.
The toolchain isn't the only thing that causes breakage. Think about the 2.1 -> 2.2 OpenSSL update.
Branching such a small(number of core developers/active testers) distro? Would it be possible?
This is how it works now, except branches are made 1-3 months prior to release and then function as a temporary trunk until the release is made. The change proposed here is actually to /only/ branch core, instead of core + opt, which in my book translates to less work. Sure, it is possible that an opt port tested on release x.y won't work on release x.y-1, but chances are very small because it's source-based.
While pushing toolchain updates 14 months into the future would probably make a relatively stable base for the next ... 14 months, it won't reduce the breakage at that point, which in turn means you'll have to do 14 months worth of head scratching.
"Small pain once a season VS medium pain once a year" question. I prefer the last.
Nobody prevents you from ignoring every second release. But enforcing that upgrade cycle on all users is wrong.