[LinuxBIOS] Patch quality
peter at stuge.se
Tue Oct 30 01:31:28 CET 2007
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,
> 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
> 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
> 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.
More information about the coreboot