Jeff Garzik wrote:
Linus Torvalds wrote:

I've long since decided that there's no point to making "-pre". What's the difference between a "-pre" and a daily -bk snapshot? Really?


Several non-BK developers use the first -rc1 as a merge point.

Others simply trust that _Linus_ has a lot more smarts than an automated script, about deciding when a good testing point should occur. Holy Penguin Pee has value, they feel.


So when I do a release, it _is_ an -rc. The fact that people have trouble understanding this is not _my_ fault.


If you want people to start testing, a good first step would be understanding why this is so.

Users have been trained that -rc means "serious bugfixes only". You are trying to re-train them. That just won't work.

When you do an -rc1 or -rc2, it is not serious bugfixes only. _Especially_ rc1. rc1 is in no way "bugfixes only." Non-BK developers just treat the first couple -rc's as a merge point, while the rest of us BK developers have already gone into "send bugfixes only" mode.

You are fighting an uphill battle against user perceptions and training.

    Jeff


Here's an idea which might just be too simple, but here it is anyway:

Modifiy the bk snapshot scripts to name the 2.6.x series snapshots as -PREy
instead of -BKy.  That way, the general population of users will see
the -bk snapshots as -pre releases.  According to Linus, pre == bk.  So,
name them as such.

Linus, wait for at least two weeks before releasing the first -rc.
That way, the bulk on the thundering herd of patches will be hopefully
be merged by then.  And users will have 2.6.x-PRE[1..14] to test.
The hard part for the kernel.org script writer might be to disable
the -bk/-pre snapshot once the first -rc is out.

Since your _intent_ is that an -rc really be an -rc, make it so.  It
shouldn't take more than a release or two to train the maintainers
that the post-2.6.11 -rc's are _really_ release candidates.

Steven

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to