Macho Hacking vs Product Development

[Werner Almesberger]

Andy Green wrote:
> If you really think there is no difference, no stress to change to the
> kernel.org style then.

The difference is in the amount of work - checking it in and going
back to it in case there are issues vs. leaving it as an uncommitted
local change, possibly blocking further local changes, waiting some
days, then going back to the old problem, and finally committing it,
possibly with some editing to separate it from things done in
between.

Also, don't worry, there's no VIP entrance for any of us to the
mainline kernel. That review will happen, just at a different place,
but also in front of a much larger audience.

By checking in immediately, I have a nicely integrated process, and
when introducing git as the main repository, you will have that too.

I also expect that we can then get more people from our team to check
in their work directly. Some of our team members have a lot of
experience with SVN and quilt, so they could do this already.

I didn't want to encourage them do work directly on the SVN repository,
though, since that may have been misinterpreted as me trying to build
an opposition to git. (Neither would I have discouraged them, though,
had they decided on that mode of operation on their own.)

The exchange of patches by mail is a consequence of having two
incompatible repositories. Since someone has to act on these mails and
has to read them in order to understand how to apply the patches, some
reviewing happens as a side-effect, but please don't try to build a
cargo cult around this.

We should have reviews before committing for contributions that don't
follow general coding style or that are high-risk or controversial in
nature. But for the bulk of our work, that shouldn't be necessary.

And yes, we have to be open to criticism. As LKML shows, also review
before committing is no protection against having to spend time on
people unwilling to cooperate.

We also have to be open to other people fixing our mistakes. There's
no shame in someone else finding flaws in our code, and if they find,
correct, and test them directly and without much ado, that helps
everyone. Obviously, should they embark on a major rewrite, that
should be discussed first.

Having changes enter the repository as quickly as possible reduces the
amount of work for the contributor, makes it easier for the reviewers
(since they can test the actual code directly), and even helps
contributors without commit access, because we all will have more time
for their contributions.

There are of course limitations to how freely we can hand out direct
commit access. It's a balance between confidence/control and also the
amount of coordination needed. As a first step after the change to
git, we should enable and encourage all internal developers to check
into the repository. "Encourage" doesn't mean that they're obliged to.
If someone prefers review-before-commit, we still have the mailing
list. But if someone never checks in directly, even when the code is
good, we should probably find out how we can change that.

Once the dust has settled, we should look into also giving external
developers who contribute on a regular basis access. E.g., I would
expect that, with time, we will have external contributors for
"special interest" areas, such as a specific subsystem or a
specific platform.

By the way, we had this discussion already during various late nights
in Taipei. I hoped getting confirmation that our mode of operation is
perfectly normal and in fact quite common had settled the issue, and
we wouldn't have to go though it all again and again :-(

- Werner