1 |
Wondering about Gentoo doing automated builds (aka tinderboxing which |
2 |
flameeyes and bonsaikitten were up to) as part of its process. Seems to be |
3 |
a move to git, and git-sha IDs came up wrt caches on dev. (If we had those |
4 |
as a digest type, they'd effectively be free to 'generate' since they'd |
5 |
already be in place.) Instead of splitting at branch level, if we split at |
6 |
repo level, so we had a QA repo where the mdata branch lived (if we did |
7 |
want to split there as well) that'd be an ideal place to base our tinderbox |
8 |
work from. (At server side the bare clone would take very little resource, |
9 |
and we could pull into a fresh clone at the build machine if it were a |
10 |
different host.) |
11 |
|
12 |
It seems silly to switch to git for development work and not take advantage |
13 |
of cheap clones to inculcate a slightly more professional process, at the |
14 |
time when it's easiest to do so. The advantage would be that we'd catch |
15 |
more errors before they went to users, and we'd have a point where we can |
16 |
start to do other more interesting things, eg around binpkgs and |
17 |
semi-frozen trees. |
18 |
|
19 |
By having it as part of Gentoo's process, there would be less need for |
20 |
externals to devote hours of CPU resource to building the whole tree, and |
21 |
bugzilla wouldn't get bombed with the results; developers would get a |
22 |
pingback (on IRC if there, by email if not) to fix their commit as it's not |
23 |
made it to the tree yet. Gentoo would not need to build whole tree over and |
24 |
over either, just the new stuff as and when it comes in. |
25 |
|
26 |
Brought this up here as it's more process than ebuild development, and can |
27 |
be moved to dev easily enough, should it warrant it. |
28 |
|
29 |
-- |
30 |
#friendly-coders -- We're friendly but we're not /that/ friendly ;-) |