| 1 |
On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner <mattst88@g.o> wrote: |
| 2 |
> I have never once been able to grab a portage snapshot and build a |
| 3 |
> stage 1, 2, 3 series from it without encountering at least a couple of |
| 4 |
> problems with the tree. |
| 5 |
|
| 6 |
Ditto - the latest issue I've run into is: 443472. Probably won't |
| 7 |
impact the average user, and perhaps I should just modify the script |
| 8 |
to not bother reading that file and figure out what the latest build |
| 9 |
is on its own. |
| 10 |
|
| 11 |
> |
| 12 |
> I think we should consider things that break release media serious |
| 13 |
> regressions. I don't know what that entails specifically, but whether |
| 14 |
> it need be QA bashing down your door or a quick fix or revert, it sure |
| 15 |
> would be nice to get Gentoo to a place where release media always |
| 16 |
> works. |
| 17 |
|
| 18 |
Agreed. If a user can't just burn a CD and then do an emerge kde-meta |
| 19 |
there is a problem. |
| 20 |
|
| 21 |
> |
| 22 |
> In short, I think the conversation we should be having should be about |
| 23 |
> how to avoid breaking release builds and how to quickly fix problems |
| 24 |
> when they're discovered. |
| 25 |
|
| 26 |
I think those working with catalyst have the most to add regarding |
| 27 |
what breaks them. |
| 28 |
|
| 29 |
As far as detect-ability goes, do we need some kind of tinderbox that |
| 30 |
just does a daily build. Perhaps just build from stage3 to a couple |
| 31 |
of world targets, including one with some server-oriented software, |
| 32 |
one with gnome, and one with kde? I've reported a bunch of bugs with |
| 33 |
the EC2 bootstrap script described on my blog (not my original work), |
| 34 |
but it is only automated from a build perspective - testing is manual. |
| 35 |
That takes about 18 hours to build (with an emphasis on economy), and |
| 36 |
I use spot instances so it really only costs maybe a buck or two. |
| 37 |
|
| 38 |
My experience has been that if it builds it usually works. So, simply |
| 39 |
testing for whether the build completes is a pretty-good first step. |
| 40 |
|
| 41 |
Of course, for system packages our recourse isn't necessarily good, |
| 42 |
since we don't have a test branch or anything like that. If we wanted |
| 43 |
to revert we'd have to impact users who already upgraded. Obviously |
| 44 |
the goal would be to fix in place with a new revbump, assuming that |
| 45 |
were possible. |
| 46 |
|
| 47 |
Rich |
Archives