>My advice is: stick to releases for now on important systems that
>you mustn't break, but also setup on a spare machine or VM that you
>don't mind breaking from time to time, use base os + package
>snapshots, maybe play with compiling a few things yourself -
>basically play around and find out what works and what doesn't.

right.

be a serious practitioner on service delivery machines.

and, on another machine, be a student.

>Generally: -current is not meant to be "unstable" in terms
>of operation, it's more that it's subject to more rapid change
>and you may occasionally have things like package breakage
>until new packages are available following API/ABI changes.

right.  it's best effort, but the effort produces really good
results.

- base is managed by one group.
- packages is managed by another group.

we communicate, but our build & network & people infrastructure
is a limited resource.  people do burn out, too.  We do what we
can.

>At hackathon times and at some other times when there are major
>changes in the tree this often gets a bit more fragile. Recently
>we've been in a "bit more fragile than usual" sort of stage. It is
>still important that people run new code in this situation and
>report on problems, but use common sense as to where you run
>this :) The reverse applies as we approach lock for release
>and changes are much more conservative. 

right.

We do what we can with the resources we've got.  Stuart's last point
is very important.  If you want the next generation product to not
be great, by all means skip the student part that pays attention to
the work in progress.  It'll suck!  Alternatively, if enough people
on the outside watch us and spot the breakages and forgive us and help
the movement move forward, then dynamically we'll solve problems that
mainstream operating systems can't solve.  Is that a good deal, or what??

>If you're following -current then I strongly recommend reading
>the source-changes mailing list (or some alternative) to get a feel
>for what's going on in the OS, and when is a good or bad time to
>upgrade.

that's a big part of the student part.  it takes a while to understand
what the mails mean.  You can read the diffs too.  Over time, you'll
see there's a vision......

Reply via email to