Gentoo Archives: gentoo-dev

From: Barry Shaw <baz@×××××××××××××××.nz>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'
Date: Sun, 04 Jul 2004 22:16:27
Message-Id: 40E881B6.2010700@scms.waikato.ac.nz
In Reply to: Re: [gentoo-dev] Policy for retirement of old gentoo 'versions' by Dylan Carlson
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 It looks like there are two separate issues here, packages in the
5 profiles being removed and an enterprise gentoo. I'm mainly concerned
6 at the moment about pinned package versions in the profiles being
7 dropped out of portage which would break any machine build based on that
8 profile.
9
10 Given that in the 1.4 and 2004.0 profiles there is only one pinned
11 package, it doesn't look like a major - its probably something that just
12 ~ the maintainer for that package should be aware of (some automated
13 check as previously mentioned would be a good safety net). If there
14 were no pinned packages in the profiles, then as long as the cat-pkg
15 names didn't change, the profile would exist indefinitely with little
16 effort on any devs part.
17
18 Now I'm not suggesting that profiles should be kept forever, but if they
19 are made redundant with little or no notice, it can cause big problems
20 if you've got hundreds of machines installed with that profile.
21
22 That said, I think an enterprise gentoo is a good idea, but its not
23 something that the devs should be lumbered with on top of maintaining
24 ebuilds. It sounds like there is more than enough to do already 8).
25 Can anyone point me in the direction of the people involved in
26 enterprise gentoo? We've got about 250 machines currently gentooed,
27 with more to come, so we might be able to offer some insights into large
28 scale installations.
29
30 |
31 | The CVS branching / Gentoo Enterprise idea (to me) sounds
32 overengineered.
33 | I haven't done a survey of IT managers to see what their expectations
34 are,
35 | but in my 14 years, management, etc -- I know what /my/ basic
36 requirements
37 | are.
38 |
39 | 1/ Conservative defaults
40 | 2/ A regular, predictable release schedule
41 | 3/ Packages are not updated between releases, except in cases of
42 | vulnerabilities or major bugfixes
43 | 4/ In the event of #3, basic regression testing before the changes are
44 | committed
45 | 5/ Supporting documentation & tools geared towards enterprise deployment
46 |
47
48 I agree, if we can get a enterprise framework that exists within most of
49 the current gentoo infrastructure, that means less work for everyone,
50 and therefore a higher chance of a sustainable project.
51
52 A stable portage tree would be the single most useful thing here. We
53 only re-sync our portage copy when security vulnerabilities are
54 announced, but due to the dynamic nature of the portage tree, this often
55 means upgrading lots of other packages in the process (e.g. mozilla 1.7
56 breaks epiphany which means a gnome 2.4 to 2.6 upgrade for us. Not a
57 big deal, but something that needs to be communicated to users before hand).
58
59 Baz
60 -----BEGIN PGP SIGNATURE-----
61 Version: GnuPG v1.2.1 (GNU/Linux)
62
63 iD8DBQFA6IG1JvZkjpKMF2wRAg0fAJ9BvwBrb7uAT3sHknaOoTkffdpDWACgs5rk
64 1q7Zv3coQQhnddHAD7Ei8vA=
65 =LQ7G
66 -----END PGP SIGNATURE-----
67
68 --
69 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Policy for retirement of old gentoo 'versions' Dylan Carlson <absinthe@g.o>