Gentoo Archives: gentoo-dev

From: "Rick \\\"Zero_Chaos\\\" Farina" <zerochaos@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] borked release media
Date: Sat, 08 Dec 2012 16:30:46
Message-Id: 50C36B59.2070001@gentoo.org
In Reply to: Re: [gentoo-dev] borked release media by Rich Freeman
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-----