[LinuxBIOS] Patch quality
peter at stuge.se
Sun Oct 28 02:58:38 CET 2007
On Sat, Oct 27, 2007 at 10:13:47AM -0700, ron minnich wrote:
> > I already published Northbridge patch, and southbridge yesterday.
> If you don't get an ack soon from someone push me and I will do it.
Please don't ack just because noone else does it. That defeats the
purpose of the reviews.
> At the same time, I am sorry to see that Morgans' stuff has fallen
> through the cracks.
At this point I think we are waiting for updated patches from SiS.
I would like to take this opportunity to address all companies that
are already supporting or are interested in supporting the project:
Thank you very much for your interest! I think it's great to be
working with you and I am confident that you've made a good choice.
With LB your products are definately able to reach new markets!
That said, it is worthwhile to keep in mind that the project has a
policy for accepting contributions and additions, with the only (but
important) purpose of maintaining the highest possible source code
quality. This includes a requirement that any non-trivial change or
addition has to be reviewed and approved (via an Acked-by line) by
other LB developers.
LB developers is a scarce resource, unfortunately. There is a high
risk for bottlenecks at the review stage. This is where it gets
interesting for you - you can help speed up the review process
1. Please talk to us (even if it is off-list) before and during major
work on the LB source code. If you are new to the code base there
will probably be at least a few things that are sort-of taken for
granted within the project, but not really documented anywhere. By
communicating at an early stage we can help you avoid these pitfalls
which we will expect you to deal with before your contributions are
2. Please always work against current SVN. This may seem problematic
if you need to do major work, but see (3) below.
3. Please send small patches to the mailing list often. This will
preempt the problem in (2) above. Small patches are much more easily
reviewed, which means that they are likely to be approved and
committed quickly. Granted - a new chipset may require a large patch,
but it is still good to first send a small patch and then build upon
it in subsequent patches.
4. Conversely, please do not ever send a tarball of your entire
development tree. It will be flat out rejected because it requires LB
developers to do a lot of extra work before any reviewing can be
done. Since LB development is a voluntary effort it could even be
considered impolite to expect someone else to do a lot of extra work
in order for your changes to be included.
5. Always expect at least two or three rounds of reviews and changes
before your patch is included. This is connected to (1) above. The
more you communicate with LB developers before and during
development, the fewer review rounds will be needed before the patch
6. Please pay close attention to the contribution guidelines on the
wiki. Make sure that things such as coding style, documentation
style, clear licensing statements, sign-off etc are all adequately
cared for in your patch. Also remember to remove any dead code that
was used only for debugging.
If you have already been involved in other open source projects, this
will be rather familiar. Hopefully you even consider it to be common
sense. If you have questions about any of our practices, please feel
free to ask us anything - we'll be happy to answer so that we can
include your contributions as quickly as possible.
We want to create world class boot software and we are very happy to
have your help! :)
More information about the coreboot