,Linus Torvalds wrote:
On Thu, 21 Sep 2006, Andrew Morton wrote:
Again, before we can implement anything we should describe what problem we are
actually trying to solve here.
Jeff: "I want faster release cycles because <no reason given>"
Me: "I want less bugs"
Anyone else?
Me: "I want peoples expectations to line up".
(That, btw, is totally independent of this particulay issue - I just like
people to know what to expect..)
One of the things that I think the current model has excelled at is how it
really changed peoples behaviour, simply because they knew and understood
the rules.
I think the "big merges in the first two weeks, and a -rc1 after, and no
new code after that" rule has been working because it brought everybody in
on the same page.
I actually expected people to dislike arbitrary rules more than they do,
but I've come to believe that people _like_ having rules that they have to
obey, as long as it's not a big pain for them. In other words, arbitrary
rules are not actually disliked at all, people actually _like_ them,
because suddenly there's less need for making unnecessary judgement
decisions.
As an example: I thought I'd get a lot of back-lash on the whole sign-off
procedure. Instead, we're basically signing off everything, and having a
few simple rules ended up making it just easier to forward stuff, and we
haven't had any of the discussions about who gets to be attributed as an
author since the sign-off was introduced. That was a totally unexpected
bonus, as far as I was concerned.
The same goes for my anal efforts at trying to make people use a specific
format for sending patches, and sending the "please pull" messages. I'm
not hearing any grumbling about it at all, and in fact I'm getting the
distinct feeling that people like knowing exactly what format to use,
because they didn't really care themselves, and it turns out that having
any rule - even if it's fairly arbitrary - seems to be better than not
having a rule at all.
So I think that a "odd release"/"even release" rule that clarifies what a
certain mid-point in the release cycle actually _means_, even if it
doesn't necessarily add anything else, might be a good thing. It just
solidifies peoples expectations about where we are in a release cycle.
If we make an arbitrary rule to go with the release cycle ("leading up to
the even cycle, you need to get an ack from somebody that actually tested
the fix") that could actually be a good thing, for this reason.
I dunno. Maybe the only arbitrary rule ends up being that an "odd release"
would become a good place for people to try, knowing that we expect bug
reports from them. Right now -rc1 might be _too_ scary, even if it ends up
being exactly that: the only difference is really not about technology,
but about what peoples expectations are.
If we could instill a culture of "if you aren't a developer, but you just
want to help out, try the odd releases", that in itself might be worth the
naming change. If it would allow a group of people who might not feel
comfortable about reporting problems with a "-rc" to feel like they are
_expected_ to report a problem with an odd release, then that would be a
good thing, no?
I'm just throwing this out as an idea. I'm not going to really argue very
strongly for it. It might have horrible downsides too, for all I know, and
we might get people who didn't get the memo on "even vs odd releases"
being really unhappy about somethign they perceive to be a buggy release.
Linus
I think it would help if you went back to using meaningful names for
releases, because 2.6.19-test1 is pretty clearly a test release even to
people who can't figure out if a number is odd or even. Then after
people stop reporting show stoppers, change to rc numbers, where rc
versions are actually candidates for release without known major bugs.
Test and rc have pretty clear meanings, anyone who puts a test release
on a production machine can't complain they didn't know, and people who
want to wait for the "should not eat your data" stage will be more
willing to try a release.
Automating testing: someone could write a simple web form to report test
results (like sign off, sort of). CPU, distribution, network, display,
filesystems used, that sort of thing. So I say FC4, Radeon-x, HT on X86,
multiple GigE, port blocking and forwarding, SNAT, TV bttv, DVD burn,
smbfs, ext3. When N people have reported no issues with a feature, you
consider it tested. If no one tests something like UML, cryptoloop, nbd,
Reiser4, or UFS, then you poke the list to try stuff. Or when a change
goes in, mark it "needs testing" on some web site. In other words
improve developer <=> tester communication without using a lot of
someone's time.
I know we have a test tracking system, but I don't see "testers needed"
messages on the list, and I'm not sure you get or use feedback from any
test tracking to identify untested features in kernels.
--
Bill Davidsen <[email protected]>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
