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 -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
