| Summary: | [DOC] Documenting development best practices using the Yocto Project | ||
|---|---|---|---|
| Product: | [Documentation] Development Manual | Reporter: | Song Liu <song.liu> |
| Component: | development | Assignee: | Scott Rifenbark <srifenbark> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | High | CC: | corneliux.stoicescu, jessica.zhang, richard.purdie, srifenbark |
| Version: | unspecified | ||
| Target Milestone: | 1.4 M4 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| URL: | http://git.yoctoproject.org/cgit.cgi/yocto-docs/commit/?id=794a13d26bb7a9e268b16f809158a6af58cc3ce8 | ||
| Whiteboard: | 14 Feb 2013 | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Song Liu
2012-10-11 00:07:14 UTC
"How to use YP in a work group?" It would be good to talk to some people using YP and see what type of development environment and flow they have set up. To start with we can at least offer some advice like: * Use git as the source control system * Maintain the metadata in layers as makes sense to your situation * Separate metadata from the code of the projects using separate git repositories * Setup sstate caches where the make sense (e.g. group of developers in the same office) either NFS or http * Setup source mirrors where it makes sense (e.g. group of developers in the same office, also share the sources directory on developer machines) * Setup an autobuilder and have it populate sources/sstate directories Making it clear that you don't have to do these things and the setup can be customised as needed but these are best practisies we've found. Links from the above items to approproiate documentation would be needed. I will start with a separate section in the YP Development Manual using Richard's rudimentary list with cross-references as applicable. We can build on it from there. Scott I have updated the dev-manual so that the basis for this information now exists. Richar suggested a new section name. However, an existing section already exists. I have added the best practices information to that section. You can see the modified section at http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-changes-collaborate. Please review and comment. Scott I have created a first draft of this section re-write based on Richard Purdie's input via an email. The draft needs reviewed. You can find it at http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-changes-collaborate. Scott Looks good, a few things I noticed: "Use a small number of high performance systems for testing purposes" -> add in that this is a shared system, the word shared should be in there somewhere to make things clear. "Of the two SCMs available (Git or Subversion)" - there are more than those available, technically you could use any bitbake supports (mercurial, cvs, subversion, perforce and others). I don't want to list them here. Perhaps just say "Of the SCMs bitbake supports, the project recommeds using git". Point at the bitbake manual for details? "Creates output that can be use for releases " -> *used* " sooner than later." looks unloved :) Reassign to Scott since I think my work on this is done. All review comments applied and a spell-check run on the chapter. Final can be viewed at http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-changes-collaborate. Closing this bug. Scott The mentioned information is contained in http://www.yoctoproject.org/docs/1.4/dev-manual/dev-manual.html#usingpoky-changes-collaborate. |