Bernie's build system workflow proposal: Difference between revisions
Jump to navigation
Jump to search
(New page: The labels are build stream names, and they're intended to be used much like git repositiories: anyone can create their own as needed, and maintainers can pull/push between them. <pre> +...) |
DanielDrake (talk | contribs) No edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
<b><font color=red><big>For information on current-day OLPC software build systems, see [[Build system]].</big></font></b> |
|||
{{Dated}} |
|||
The labels are build stream names, and they're intended |
The labels are build stream names, and they're intended |
||
to be used much like git repositiories: anyone can create |
to be used much like git repositiories: anyone can create |
||
| Line 24: | Line 28: | ||
+---------------------------+ |
+---------------------------+ |
||
</pre> |
</pre> |
||
The advantage of a system like this one is that makes the process of distinguishing high-quality build-patches from low-quality ones into a close analogue of the one used for distinguishing high-quality source-code patches from low-quality ones. |
|||
Latest revision as of 16:55, 8 February 2011
For information on current-day OLPC software build systems, see Build system.
|
The currency of this article or section may be limited by out-of-date information. There may be relevant discussion on its talk page |
The labels are build stream names, and they're intended to be used much like git repositiories: anyone can create their own as needed, and maintainers can pull/push between them.
+-----+ +-----+ +------+ +------+
|marco| |tomeu| |bernie| |mstone| (unstable trees)
+-----+ +-----+ +------+ +------+
| | | |
v v | |
+---------+ | |
| sugar | | | . . (pull)
+---------+ | |
| | |
V V V
+- - - - - - - - - - - - - -+
| testing | (kim, jim, walter, alex)
+- - - - - - - - - - - - - -+
|
V
+---------------------------+
| stable |
+---------------------------+
The advantage of a system like this one is that makes the process of distinguishing high-quality build-patches from low-quality ones into a close analogue of the one used for distinguishing high-quality source-code patches from low-quality ones.