[LinuxBIOS] Patch quality

Paul Menzel paulepanter at users.sourceforge.net
Sun Oct 28 10:36:14 CET 2007


Hi,


Am Sonntag, den 28.10.2007, 02:58 +0100 schrieb Peter Stuge:
> On Sat, Oct 27, 2007 at 10:13:47AM -0700, ron minnich wrote:

> 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
> considerably:
> 
> 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
> accepted.
> 
> 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
> is accepted.
> 
> 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! :)

This is a nice write-up and summary. Therefore I would like to see this
in the wiki. But I have not been able to come up with a nice wiki-title

- Patch Quality (does not fit, IMHO)
- Hints for contibuting companies / contributors

and where to link to it from.

If someone can answer the two issues above and nobody minds, I will add
it to the wiki.


Greetings,

Paul





More information about the coreboot mailing list