1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 12/08/2012 06:50 AM, Rich Freeman wrote: |
5 |
> On Sat, Dec 8, 2012 at 12:25 AM, Matt Turner <mattst88@g.o> wrote: |
6 |
>> I have never once been able to grab a portage snapshot and build a |
7 |
>> stage 1, 2, 3 series from it without encountering at least a couple of |
8 |
>> problems with the tree. |
9 |
> |
10 |
> Ditto - the latest issue I've run into is: 443472. Probably won't |
11 |
> impact the average user, and perhaps I should just modify the script |
12 |
> to not bother reading that file and figure out what the latest build |
13 |
> is on its own. |
14 |
> |
15 |
>> |
16 |
>> I think we should consider things that break release media serious |
17 |
>> regressions. I don't know what that entails specifically, but whether |
18 |
>> it need be QA bashing down your door or a quick fix or revert, it sure |
19 |
>> would be nice to get Gentoo to a place where release media always |
20 |
>> works. |
21 |
> |
22 |
> Agreed. If a user can't just burn a CD and then do an emerge kde-meta |
23 |
> there is a problem. |
24 |
> |
25 |
>> |
26 |
>> In short, I think the conversation we should be having should be about |
27 |
>> how to avoid breaking release builds and how to quickly fix problems |
28 |
>> when they're discovered. |
29 |
> |
30 |
> I think those working with catalyst have the most to add regarding |
31 |
> what breaks them. |
32 |
> |
33 |
> As far as detect-ability goes, do we need some kind of tinderbox that |
34 |
> just does a daily build. Perhaps just build from stage3 to a couple |
35 |
> of world targets, including one with some server-oriented software, |
36 |
> one with gnome, and one with kde? I've reported a bunch of bugs with |
37 |
> the EC2 bootstrap script described on my blog (not my original work), |
38 |
> but it is only automated from a build perspective - testing is manual. |
39 |
> That takes about 18 hours to build (with an emphasis on economy), and |
40 |
> I use spot instances so it really only costs maybe a buck or two. |
41 |
|
42 |
I build about ~1300 packages for amd64 and x86 nearly every day from a |
43 |
fresh snapshot. I'm working on automating it so it really is every day. |
44 |
Once it is automated I suppose I can add kde-meta to the list, even |
45 |
though... well... it's kde. |
46 |
|
47 |
- -Zero |
48 |
> |
49 |
> My experience has been that if it builds it usually works. So, simply |
50 |
> testing for whether the build completes is a pretty-good first step. |
51 |
> |
52 |
> Of course, for system packages our recourse isn't necessarily good, |
53 |
> since we don't have a test branch or anything like that. If we wanted |
54 |
> to revert we'd have to impact users who already upgraded. Obviously |
55 |
> the goal would be to fix in place with a new revbump, assuming that |
56 |
> were possible. |
57 |
> |
58 |
> Rich |
59 |
> |
60 |
> |
61 |
|
62 |
-----BEGIN PGP SIGNATURE----- |
63 |
Version: GnuPG v2.0.19 (GNU/Linux) |
64 |
Comment: Using GnuPG with undefined - http://www.enigmail.net/ |
65 |
|
66 |
iQIcBAEBAgAGBQJQw2tZAAoJEKXdFCfdEflKrh4P/i1aJCtnVWh5IlTJ5QMd36S+ |
67 |
eE6chQuZGpm+7TLUsGkRG3rfTKe1vTkDj+e0R5KNQTWL3URsfo9Bc+x87EKBDlZd |
68 |
xkx2VRA+AojFcKwJzUDznwAwCYRz9NIhEz+6bX/Gd0w1PR7ig6JucPa9e6dj4XqG |
69 |
pWvf9me3D78WuNOGcQ70jYX7JxNr0+vzzRu0e4EoEphSLYzIPpdz2FIs6CHov0qD |
70 |
y/imKNG8TjpWRP6/It4s3+83B6nsPfGl9JcwlMXjqncAXNHc0WStFWx5oV/NfqT/ |
71 |
myvV/90YdY2oI5++RcWXsI52aEYuTfvnxZM1WghiymW0UVdR7r7OYMHbiE3Tq59f |
72 |
p8kLgGSxwyleOQHmX9o822mIF53A2PRZ/FEs6Jhr7r1R/NTnvMnePQUUMEAntwlq |
73 |
DjPKui7MhQr8KgnekAqw6EU42spgyKc22QXvp2rdAUnviBA5+c5CtU3RDvx5b9GO |
74 |
VDvuCCI24fsXe9/HyKknoyLjMwfQGHIFp8Cy3oLG40pT9LLzip+jehdv+Kdmy7nX |
75 |
x69bsEioIoVw23wtuWou1+a+HAlfZzTQWlr4TbeAZug9V1YGg9HxP/amzxOrBbcs |
76 |
qbT4Rtf332Kzx4FqYfU/ex6uaMN9fHLv6MAfS5D0l3+P5KK9zMc5P8Tlla3pRFZN |
77 |
I0g6imtLeVA0pMQFgsym |
78 |
=2tcz |
79 |
-----END PGP SIGNATURE----- |