Matthew Miller píše v Po 30. 08. 2010 v 18:56 -0400:
On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote:
> A typical developer wants the dependencies of the software they are
> working on to be _very_ up to date - probably not the upstream
> development version, but the upstream maintenance version with _all_
> current bug fixes. Waiting 6 months for a bug fix does not make sense -
> at that point the developer would be tempted to build the new version
> locally.
[...]
> Saying "use rawhide" is not helpful, because rawhide is very often
> broken.
I've been running rawhide as my primary desktop OS at work for a couple of
years now. During that time, it's only broken so as to cause me as much as a
couple of hours work twice. That seems like a small price to pay for being
on the extreme leading edge as you describe.
Curious. My experience from using the
latest Fedora (often updating on
the date of GA release) is very similar.
I sometimes wonder what the other users of Fedora are doing that the
"updates firehose" is such a problem...
> A "stable" release that breaks a specific component
for a few
> days is acceptable - if this is not a component one uses for
> development, it doesn't matter; if this is such a component, one knows
> about it well enough to be able to revert an update or to contribute a
> fix.
There you go! That's what we have in Rawhide.
No, for rawhide to really be
useful, it must be possible to put
unfinished system-wide changes in there: it would be pretty much
impossible to integrate systemd into the distribution on a "branch", and
to add it into rawhide only after everything works 100%. rawhide is
here to allow integration of "80% working but not finished" code, and
polishing it. As such, it is unavoidably dangerous, even if it may
often work out fine.
What I was talking about originally is not "80% working but not
finished", but "as far as we know 100% working, but not tested by a
RHEL-equivalent QA process including two beta releases over 6 months".
Mirek