* Peter Stuge peter@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