1 |
On Mon, 2005-08-29 at 20:42 -0400, Alec Warner wrote: |
2 |
> >No. *I* could not because *I* think it is a waste of time. I care |
3 |
> >about exactly one profile, in honesty, the one I use to build the |
4 |
> >release. If there were 10,000 other profiles, I wouldn't care. |
5 |
|
6 |
> and *I* can't make a tree-wide server profile because *I* don't have a) |
7 |
> commit access and b) a minimal profile to derive from other than |
8 |
> default-linux, and thats yours and you said you will not let it be |
9 |
> changed. Plus default-linux is far too minimal. So *I* have to jump on |
10 |
> -dev and convince others ( not necessarily you, mind ) that a profile of |
11 |
> this nature is a good idea, so *I* don't end up having to duplicate tons |
12 |
> of work making a default profile for every arch I run. |
13 |
|
14 |
a) not my problem... ;] |
15 |
b) default-linux isn't mine... default-linux/x86/2005.1 is... get the |
16 |
distinction now? |
17 |
|
18 |
A server profile should be separate anyway. It shouldn't have |
19 |
*anything* to do with the release profiles, since we aren't releasing |
20 |
it. This seems to be the point everyone is missing. There's nothing |
21 |
stopping anyone from making as many profiles to do as many things as |
22 |
they want, I simply ask them to not muck with the release's dated |
23 |
profiles. |
24 |
|
25 |
> >>you could also do default-linux/x86/2005.1/release or whatnot if you want |
26 |
> >>to maintain that as well. |
27 |
> >> |
28 |
> >> |
29 |
> > |
30 |
> >Why? Would you not expect the 2005.1 Handbook plus the 2005.1 media |
31 |
> >plus the 2005.1 profile to produce a 2005.1 system? Why would I need a |
32 |
> >"release" sub-profile to distinguish it as a release? Is that not |
33 |
> >completely redundant? |
34 |
> > |
35 |
> > |
36 |
> The plan with having a release sub-profile was making the |
37 |
> default-linux/${ARCH}/${RELEASE}/ a minimal profile and then have the |
38 |
> /release subprofile be 'normal', and taking a second look really no |
39 |
> different from a "desktop" subprofile other than better naming. |
40 |
|
41 |
No. |
42 |
|
43 |
I have no problem with making the default-linux/${ARCH} profile minimal, |
44 |
as I tend to agree that it should be, but the dated profiles should |
45 |
match what is released. Doing anything else really is plain asinine as |
46 |
the "2005.1" stage tarball should match the "2005.1" profile. Or would |
47 |
you rather we start calling the tarballs "2005.1-release", which is |
48 |
*really* redundant? |
49 |
|
50 |
> as far as profiles, there is no documentation that I can find on who |
51 |
> 'owns' profiles and does work on them. Sorry if you end up doing all |
52 |
|
53 |
Nobody really "owns" them, at all. In general, the arch teams maintain |
54 |
their own. Nobody touches default-linux unless absolutely necessary. |
55 |
For the x86 profiles, releng has been maintaining them since it was |
56 |
born, with a few people interjecting fixes here and there. |
57 |
|
58 |
> the work on default-linux, I will focus my efforts elsewhere if that is |
59 |
> the case. I just know that for the majority of profiles |
60 |
> default-linux/arch is what most of them inherit from, so thats where the |
61 |
> party started ;) |
62 |
|
63 |
Most of the profiles are also based on the idea of being modifications |
64 |
or extensions from the release's profiles. You're talking about |
65 |
something completely divergent. |
66 |
|
67 |
Notice something with me. When you look for the hardened profiles, you |
68 |
don't look under profiles/default-linux/${ARCH}/${RELEASE}/hardened, do |
69 |
you? Why not? Because they're divergent enough that doing the |
70 |
inheritance from a release profile makes it more work than not. It's |
71 |
really that simple. Nobody would have a problem with them using |
72 |
profiles/default-linux/${ARCH}/${RELEASE}/hardened. They don't because |
73 |
it doesn't make sense for them to do so. I tend to think any "server" |
74 |
profiles would fall under the same thinking. |
75 |
|
76 |
-- |
77 |
Chris Gianelloni |
78 |
Release Engineering - Strategic Lead/QA Manager |
79 |
Games - Developer |
80 |
Gentoo Linux |