The Old Way Was Better

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 9 Sep 2003, Jamie Bowden wrote:

> Which is fine, but the gist of my question is whether or not we can expect
> to see the sort of stringent -CURRENT testing of code prior to MFC to
> -STABLE once the merge takes place and FBSD is no longer tracking two
> concurrent releases?

No, we plan to commit stuff to RELENG_5 willy nilly, with no regard for
our users. (C'mon, what kind of answer did you expect to a question like
that?) :)

> The PAO issues would never have been allowed in the past, it would
> have immediately been backed out as soon as it became apparent that it
> was a show stopper of a bug.

I took a member of the re@ team to task on that very topic last night as
I held him captive in my car on the way to dinner at the 'con. :)
Personally, I wouldn't have allowed the PAE stuff, or the ata bus dma
changes into RELENG_4 at all, but it's easy to sit on the sidelines and
grouse about stuff... the release engineers generally do a good job
treading the fine line between too much progress, and not enough.

> Bugs made it into -S in the past; -C users are a limited subset, but
> if something made it into -S that wasn't ready, it was immediately
> pulled back out of the public CVS repo until it was tracked and
> squished.

Your view of history is a little rosy here. Also, my _personal_ view
of the thing is that I'd like to see the -stable branch be a little
looser on imports prior to a freeze, and have a little bit longer of a
freeze that's a real freeze. Then we can make the releases really solid,
and let the RELENG_5_X branches be the safe landing point for people
that want to try the new stuff, but don't have as much tolerance for
getting bitten in the butt by bug smashing that will be ongoing in
RELENG_5 for a while even after the tree is branched.

> As I said in my original entry point to this thread, I know the
> project is tracking two concurrent releases right now, so there are
> some accomodations being made, resources are scarce, this is a free
> project built by volunters, etc.  Those resources hopefully won't be
> so stretched come the 5-STABLE branch later this month.

Who said next month? :)  I'm hoping that we push the branch point back
to 5.3 as things stand right now.... we need to get a mostly stable 5.2
out the door so that people can start testing the stuff that's gone in
since 5.1, but we're close enough to being "done" with some of the
really big changes right now that waiting another 3 months for the
branch is almost certainly the right thing to do.

Doug

- -- 

    This .signature sanitized for your protection

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/XmD1yIakK9Wy8PsRAvlEAJ91LkP4jJRLVDpfQ2PS+ywTvLFQPwCgiv67
spqPmvZkjeSPDHZNEXnAAX0=
=BJCO
-----END PGP SIGNATURE-----