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
-
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]
