[LinuxBIOS] Patch quality

[Stefan Reinauer]

* Peter Stuge <peter at stuge.se> [071030 01:31]:
> > but few want to spend a lot of valuable money and engineering
> > resources on it -
> 
> All business moves require an investment. Some resources will always
> be neccessary, be it money, sending out hardware samples, engineering
> resources or documentation resources.

I certainly agree on the investment. But: I would not visit a
restaurant twice, no matter how delicious the food is, if the waiter
annoys me and takes 2 weeks before getting me seated.

> And they can. I understand this desire and the frustration newcomers
> experience from the review/revision process we practise on the list.
> 
> My point was that new contributors can save work and time (get
> patches committed sooner) by communicating with the project not only
> when the patch is submitted but also before and during the
> development.
 
This is also a matter of attitude. We should take this contribution as
an "early communication" that we can use and improve until the final
work results from it. A work where the community contributes its part,
as does the vendors.

Trying to educate people how to indent is pretty common in the open
source world, but is also kind of rude. We are very well capable of
indenting and beautifying the LinuxBIOS code ourselfes. No need to
torchure any vendor contributor with that.

> The way I see it, there is a competitive advantage for vendors who
> _do_ submit code because they will have support for their hardware
> much sooner than if they only contributed documentation and relied
> on volunteers to write the code.

I absolutely agree. The number of ports that came out of just for fun
development for a single board is rather small. It is very cool that it
does happen though.

> Yes and no. We are interested in the project so it's likely that
> someone eventually finds the time to work through a huge workload
> that would benefit the project. I think the best example of this is
> the MCP55 support. What I wanted to convey and probably should have
> emphasized more is that it will take much longer if volunteers need
> to do a lot of work before the code is committed.
 
I think the MCP55 is an excellent example. The code has been checked in
for a while, and people start using it in more unusual constellations.
Suddenly patches from all kinds of people start coming in. A few lines
here, a few lines there, constantly improving the result.

Imagine this would have resulted from a code review. This would put the
pressure on a single committer and keep the code from being available
for improvement in the repository. 

I am glad it did not stick in the review loop unless all GPIO issues
were sorted out.

> > Tossing these back into the face of vendor who really would rather
> > not be here
> 
> Either a vendor thinks it's a good business move or they don't.

This is the starting point. In the beginning of LinuxBIOS no vendor
thought it would be. We convinced some of them. Why should we stop
convincing them now? One way of convincing people if by making them feel
understood and taken care of.

> It could probably use a revision after this great review round,
> especially if it's going to the wiki.
> 
> I did not want to set rules in stone, rather I wanted to distill the
> practises we employ into concrete advice for new contributors so that
> they could make the most of their time working with the project.
 
You did a very good job bringing it to electrons (rather than stone)

Being a successful project, we should think about what vendors can do
for us, and also what we can do for the vendors. Manus manum lavat.

> We can't do anything after the fact. If a vendor dumps a huge patch,
> or a tree with tons of changes, on us and runs, we just don't have
> the resources to review and commit over night.
 
We are usually having huge delays, even though they do not really help
the process but are caused by the hurdle of our "process". 
The "process" needs to be optimized to our needs. If there's a simple
trick we can do to enable more people to improve what a contributor like
Morgan gives us, we should definitely take the chance and do it.

> Of course we could fix up any problems we notice, but that's usually
> left to the original contributor.

I think this proved top be an exhausting model in the last couple of
months. 

> Spot on. I think it starts long before the final patch is sent.
 
There is no such thing as final. We are constantly moving and
innovating  ;-)

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866