This is really great discussion!
On Mon, Oct 29, 2007 at 09:57:38AM -0600, Jordan Crouse wrote:
I was just very worried that we might have lost another board.
Which is a very reasonable and real fear.
Board no, vendor maybe.
In fact, forst most, this is their first foray into the world of open source.
True. It's important that we make contributors feel welcome.
They are here to present their products because they believe that participation in LinuxBIOS is a good business move,
Indeed.
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.
they want to dump the code and run so to speak.
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.
But we also need to realize that, at this point, we are completely dependent on the vendors to advance this project.
We certainly need information from vendors, but I don't think we're dependent on them for code.
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.
If they are willing to buy into the coding standards and the loftier ideas of the open source creedo, then more power to them, and we thank them. But if not, then *we* need to take up the slack, and handle the style and other issues that turn good code into great code.
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.
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. Again - no business without investment. I'd like to reduce the investment.
is just incentive for them to storm off and say bad things about us behind our back.
We should be easy to work with, I agree completely.
Peter's manifesto, while correct, and reflecting our best intentions, is sure not to help the matter at all.
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.
The vendors we so desperately need just don't buy into it. Sorry.
If you're saying that vendors can't be bothered to work with the project then all I'm saying is that it will take longer for their hardware to be supported.
On Mon, Oct 29, 2007 at 03:51:38PM -0700, ron minnich wrote:
I'm not sure if SiS is coming back, and I wouldn't be surprised if they didn't.
Translation: we, collectively, need to do better. I realize we're all volunteers, and this is a 'time available' activity. Given that, what can we do better to make this smoother for people?
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.
This is the 'shepherd' model.
I like the idea.
This team would form dynamically and communicate (via the list?) on the changes that have to be made. But people would have to sign up for a given piece, and a deadline.
(I don't really believe in deadlines in open source projects, but that's just me, and a side track.)
But if we can't do better when someone like Morgan comes in, it's going to hurt us.
I think it hurts the contributor equally, assuming they actually want their code to be committed.
I don't feel (me included) that we did what we needed to do. The 'code critique' approach works in some cases, but
Without hardware or documentation there is not much more to be done.
Of course we could fix up any problems we notice, but that's usually left to the original contributor.
for those who need more assistance, we need a different procedure, which would be more active and helpful.
Spot on. I think it starts long before the final patch is sent.
//Peter