[gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thursday 12 August 2004 17:01, Jason Huebel wrote:
>
> K, since I'm the release maintainer for amd64, I'm going to chime in on
> this. This may not be a popular opinion, but so be it.
>
> I am of the opinion that a new profile should be part of each new Gentoo
> release.  It may be confusing for the user if s/he is using a 2004.0
> profile with a 2004.2 release.  Whether there are significant profile
> changes or not, Gentoo 2004.0 has a 2004.0 profile, 2004.2 has a 2004.2
> profile, and 2004.3 will have a 2004.3 profile. And so on...  The only
> exception has been 2004.1, but I was still relatively new to being a
> release maintainer and hadn't formulated a solid opinion on profiles.
>
> For the release maintainers, creating a new profile is very simple and
> quick. For users, updating to the new profile is also very simple and
> quick. I fail to see the big problem here.

From what I remember this was not the initial idea. Maybe your position is 
better, but some discussion might be appropriate. I think it should be done 
consistently for the different architectures.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Thursday 12 August 2004 12:36 pm, Paul de Vrieze wrote:
> From what I remember this was not the initial idea. Maybe your position is
> better, but some discussion might be appropriate. I think it should be done
> consistently for the different architectures.

If the idea has been that profiles don't necessarily track the version of the 
release, then I think profiles should have a different version numbering 
scheme.  Using 2004.0, 2004.1, 2004.2, etc implies that the profile should be 
tracking with the release.

2 cents.. cha-ching!

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Thu, 2004-08-12 at 18:05, Jason Huebel wrote:
> On Thursday 12 August 2004 12:36 pm, Paul de Vrieze wrote:
> > From what I remember this was not the initial idea. Maybe your position is
> > better, but some discussion might be appropriate. I think it should be done
> > consistently for the different architectures.
> 
> If the idea has been that profiles don't necessarily track the version of the 
> release, then I think profiles should have a different version numbering 
> scheme.  Using 2004.0, 2004.1, 2004.2, etc implies that the profile should be 
> tracking with the release.
> 
> 2 cents.. cha-ching!

Precisely! When seemant and I first talked about the cascading profile
implementation, we had every intention of avoiding release specific
versioning scheme. AFAIK, this is still the case. I still think that
this is the best route to follow due to the fact that not much changes
between releases. If there are special cases (take xorg for example), we
can always make an exception to the rule. 

Cheers,

-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

On Thursday 12 August 2004 6:20 pm, John Davis wrote:
> Precisely! When seemant and I first talked about the cascading profile
> implementation, we had every intention of avoiding release specific
> versioning scheme. AFAIK, this is still the case. I still think that
> this is the best route to follow due to the fact that not much changes
> between releases. If there are special cases (take xorg for example), we
> can always make an exception to the rule.

Maybe it would make more sense to have yearly refreshes of the profiles, with 
profile "revisions" during the year using -r#. For instance, 2004 would have:

default-linux/amd64/2004 (equivalent to the 2004.0 profile)
default-linux/amd64/2004-r1 (equivalent to the 2004.2 profile)

Then next year (even though it isn't strictly necessary), we could have:

default-linux/amd64/2005

It would basically be the same as the last 2004 revision, but I can't think of 
a better major version number than using the year.  Then we could have 
revisions after that.

Actually, we might even be able to do something like this:

default-linux/amd64/2005/r0
default-linux/amd64/2005/r1

... and so on.  Thoughts?

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Thu, 2004-08-12 at 19:36, Jason Huebel wrote:
> On Thursday 12 August 2004 6:20 pm, John Davis wrote:
> > Precisely! When seemant and I first talked about the cascading profile
> > implementation, we had every intention of avoiding release specific
> > versioning scheme. AFAIK, this is still the case. I still think that
> > this is the best route to follow due to the fact that not much changes
> > between releases. If there are special cases (take xorg for example), we
> > can always make an exception to the rule.
> 
> Maybe it would make more sense to have yearly refreshes of the profiles, with 
> profile "revisions" during the year using -r#. For instance, 2004 would have:
> 
> default-linux/amd64/2004 (equivalent to the 2004.0 profile)
> default-linux/amd64/2004-r1 (equivalent to the 2004.2 profile)
> 
> Then next year (even though it isn't strictly necessary), we could have:
> 
> default-linux/amd64/2005
> 
> It would basically be the same as the last 2004 revision, but I can't think of 
> a better major version number than using the year.  Then we could have 
> revisions after that.
> 
> Actually, we might even be able to do something like this:
> 
> default-linux/amd64/2005/r0
> default-linux/amd64/2005/r1
> 
> ... and so on.  Thoughts?


I like the major versioning, but do we really need the minor versions? I
see that as a throwback to what we are doing now. The reason that I want
to drop release-based versioning is to avoid the needless replication of
data since the profiles between same year releases are so similar.

BTW - we really should start a GLEP about this ;)

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Thursday 12 August 2004 7:52 pm, John Davis wrote:
> I like the major versioning, but do we really need the minor versions? I
> see that as a throwback to what we are doing now. The reason that I want
> to drop release-based versioning is to avoid the needless replication of
> data since the profiles between same year releases are so similar.
>
> BTW - we really should start a GLEP about this ;)

Well, it's not that we have minor versions.  Frankly there may be years where 
the first major version is all we need.  But specifying that a revision 
number is the accepted minor version would simply eliminate confusion.  I 
don't see how we could get away from some type of minor version, considering 
we had one significant profile change this year when we moved to xorg-x11.  I 
know that amd64 is planning to have at least one more significant change when 
we move to gcc 3.4 in 2004.3.

As far as the GLEP, I think we should finish hashing it out here, then write 
it up. :-) This is a very constructive discussion so far. We could decide to 
write the GLEP when things digress. ;-)

So, I still think using the year as the major version, with a revision number 
as the minor version (only for -r1 or greater) is a good way to go.  But 
you're the head releng dude, so it's up to you.  But I think we should at 
least get away from using .1, .2, etc in the profiles.

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On Thu, 2004-08-12 at 21:08, Jason Huebel wrote:
> On Thursday 12 August 2004 7:52 pm, John Davis wrote:
> > I like the major versioning, but do we really need the minor versions? I
> > see that as a throwback to what we are doing now. The reason that I want
> > to drop release-based versioning is to avoid the needless replication of
> > data since the profiles between same year releases are so similar.
> >
> > BTW - we really should start a GLEP about this ;)
> 
> Well, it's not that we have minor versions.  Frankly there may be years where 
> the first major version is all we need.  But specifying that a revision 
> number is the accepted minor version would simply eliminate confusion.  I 
> don't see how we could get away from some type of minor version, considering 
> we had one significant profile change this year when we moved to xorg-x11.  I 
> know that amd64 is planning to have at least one more significant change when 
> we move to gcc 3.4 in 2004.3.
> 
> As far as the GLEP, I think we should finish hashing it out here, then write 
> it up. :-) This is a very constructive discussion so far. We could decide to 
> write the GLEP when things digress. ;-)
> 
> So, I still think using the year as the major version, with a revision number 
> as the minor version (only for -r1 or greater) is a good way to go.  But 
> you're the head releng dude, so it's up to you.  But I think we should at 
> least get away from using .1, .2, etc in the profiles.

I can do with a revision number as the minor version, as long as it is
the exception, not the rule ;) I agree as well that we should get away
from the .x stuff.

I am fine with the proposal that we have and am ready to GLEP it if
there are no further comments.

Thanks for the constructive discussion :)

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Fri, 2004-08-13 at 01:38, Seemant Kulleen wrote:
> you know, this maybe silly, but I do kind of like not having version
> numbers at all, and maybe making the profile names more descriptive
> 
> so in the amd64 profile, you'd have gcc34, for example
> and in all of them, we could have xfree and xorg profiles.
>   Thoughts?

I could see either way working. The nice thing about your proposal is
that it cuts all of the bloat associated with version numbering. The
only con that I can see is that it does not offer a standardized way of
marking profile revisions like jhuebel's does (-r1, -r2, no matter what
the arch or the change).

Since this is a good comment, I am forwarding it to the list ;)

Regards,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

On Friday 13 August 2004 9:20 am, John Davis wrote:
> On Fri, 2004-08-13 at 01:38, Seemant Kulleen wrote:
> > you know, this maybe silly, but I do kind of like not having version
> > numbers at all, and maybe making the profile names more descriptive
> >
> > so in the amd64 profile, you'd have gcc34, for example
> > and in all of them, we could have xfree and xorg profiles.
> >   Thoughts?
>
> I could see either way working. The nice thing about your proposal is
> that it cuts all of the bloat associated with version numbering. The
> only con that I can see is that it does not offer a standardized way of
> marking profile revisions like jhuebel's does (-r1, -r2, no matter what
> the arch or the change).
>
> Since this is a good comment, I am forwarding it to the list ;)

This is my concern. It seems to me that we still really need to hold on to 
some type of versioning scheme that indicates a progression over time.

I'll just leave it at that. I just wanted to indicate my agreement... :-)

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

Jason Huebel wrote:[Thu Aug 12 2004, 07:36:02PM EDT]
> Maybe it would make more sense to have yearly refreshes of the
> profiles, with profile "revisions" during the year using -r#.

What's the point of the yearly refreshes?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

On Friday 13 August 2004 8:39 am, Aron Griffis wrote:
> > Maybe it would make more sense to have yearly refreshes of the
> > profiles, with profile "revisions" during the year using -r#.
>
> What's the point of the yearly refreshes?

Honestly, those yearly refreshes would be a duplication of effort.  However, 
if we use the year as the major number, it seems to me that the first release 
for each year should include a refresh of the profile as well, just to track 
with the year's releases.  It's less duplication of effort than the current 
flat-profile scheme, but still maintains an understandable progression.

There's no point in simplifying the versioning scheme if we're unwilling to do 
any "cleanup maintenance".  There is going to be some duplication, period. 
But that duplication (minimized as much as possible) is what makes a 
well-maintained set of profiles.

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[William Hubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Aug 13, 2004 at 09:59:27AM -0500, Jason Huebel wrote:
> On Friday 13 August 2004 8:39 am, Aron Griffis wrote:
> > > Maybe it would make more sense to have yearly refreshes of the
> > > profiles, with profile "revisions" during the year using -r#.
> >
> > What's the point of the yearly refreshes?
> 
> Honestly, those yearly refreshes would be a duplication of effort.  However, 
> if we use the year as the major number, it seems to me that the first release 
> for each year should include a refresh of the profile as well, just to track 
> with the year's releases.  It's less duplication of effort than the current 
> flat-profile scheme, but still maintains an understandable progression.
> 
> There's no point in simplifying the versioning scheme if we're unwilling to do 
> any "cleanup maintenance".  There is going to be some duplication, period. 
> But that duplication (minimized as much as possible) is what makes a 
> well-maintained set of profiles.

I don't see why we need the yearly refreshes either.

I like the suggestion of making the names more descriptive in stead of using numbers.
Fore example, default/linux/am64.
Then, you might have default/linux/am64/gcc34.
Suppose that you decide to make the default am64 profile use gcc 3.4.  All you have to do is merge the am64/gcc34 profile into the am64 profile.
You could do this type of merging with any revision you want to become part of the default profile, and otherwise not change the default profile at all.

What do you think?

William

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBHQ9UblQW9DDEZTgRAvaUAJ9lgCqUMO1g0SHDVw4gFPPuQzyRwwCeNeN/
AGISNaH8omBmeok77WF57Dg=
=vm+k
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Friday 13 August 2004 1:58 pm, William Hubbs wrote:
> I don't see why we need the yearly refreshes either.
>
> I like the suggestion of making the names more descriptive in stead of
> using numbers. Fore example, default/linux/am64.
> Then, you might have default/linux/am64/gcc34.
> Suppose that you decide to make the default am64 profile use gcc 3.4.  All
> you have to do is merge the am64/gcc34 profile into the am64 profile. You
> could do this type of merging with any revision you want to become part of
> the default profile, and otherwise not change the default profile at all.
>
> What do you think?

Again I'm concerned that there isn't a built-in revision history outside of 
CVS using this method.  Since users don't have CVS access, they don't have a 
convenient way to tell which profile is the "newest".  Since we can't be sure 
that everyone has moved off a particular profile, we have to keep ALL the 
profiles around for an extended period of time.  So not having a revision 
history makes it more difficult to understand what the latest and greatest 
is.

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[William Hubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Aug 13, 2004 at 02:08:59PM -0500, Jason Huebel wrote:
> On Friday 13 August 2004 1:58 pm, William Hubbs wrote:
> > I don't see why we need the yearly refreshes either.
> >
> > I like the suggestion of making the names more descriptive in stead of
> > using numbers. Fore example, default/linux/am64.
> > Then, you might have default/linux/am64/gcc34.
> > Suppose that you decide to make the default am64 profile use gcc 3.4.  All
> > you have to do is merge the am64/gcc34 profile into the am64 profile. You
> > could do this type of merging with any revision you want to become part of
> > the default profile, and otherwise not change the default profile at all.
> >
> > What do you think?
> 
> Again I'm concerned that there isn't a built-in revision history outside of 
> CVS using this method.  Since users don't have CVS access, they don't have a 
> convenient way to tell which profile is the "newest".  Since we can't be sure 
> that everyone has moved off a particular profile, we have to keep ALL the 
> profiles around for an extended period of time.  So not having a revision 
> history makes it more difficult to understand what the latest and greatest 
> is.

Hmmm, I guess I'm thinking that for general use the latest and greatest would be /default-linux/<arch>.  Any changes would be in /default-linux/<arch>/<something> for a while, then if it is decided that that change should be made part of the profile for <arch>, it would be merged into that profile then the
/default-linux/<arch>/<something> profile would be depricated.

I guess I'm seeing any subdirectory under /default-linux/<arch> as either a special-purpose profile of some kind, or a way to test changes to the profile before they are put into the main profile for that architecture.

What do you think?

William

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBHTEEblQW9DDEZTgRAnoNAJ9VW5wo674vyAwdAIpPXhEEr024igCgg/Cy
ue7wSzUQRCKLZnsJ6vydBnE=
=QOa2
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

On Fri, 2004-08-13 at 17:22, William Hubbs wrote:
> Hmmm, I guess I'm thinking that for general use the latest and greatest would be /default-linux/<arch>.  
> Any changes would be in /default-linux/<arch>/<something> for a while, then if it is decided that that change
> should be made part of the profile for <arch>, it would be merged into that profile then the
> /default-linux/<arch>/<something> profile would be depricated.
> 

Its a good idea, but quite vague. What you are proposing is more or less
what we do now ;)

> I guess I'm seeing any subdirectory under /default-linux/<arch> as either a special-purpose profile of
>  some kind, or a way to test changes to the profile before they are put into the main profile for that architecture.
> 

Developers can use whatever name they want to for unoffical profiles:

For example, a testing gcc3.4 profile (full dir layout here)

/default-linux
-x86
 -/2005
 -/2005.1
 -/gcc34

Once that profile is stable and tested, it can be merged into a 2005.2.
At that time we would deprecate the older profile if needed.

I would really rather that we go the route that jhuebel proposed. It is
not overly structured, but it gives enough structure as to keep our
profile dir a bit more intuitive. If we document what is in each profile
(default-linux/$arch/ChangeLog perhaps?) and stick to a standard naming
scheme, I honestly believe that we will be better off in the long run.
Consistency across the board is a Good Thing (TM).

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

On Fri, 2004-08-13 at 14:58, William Hubbs wrote:
> I don't see why we need the yearly refreshes either.
> 
> I like the suggestion of making the names more descriptive in stead of using numbers.
> Fore example, default/linux/am64.
> Then, you might have default/linux/am64/gcc34.
> Suppose that you decide to make the default am64 profile use gcc 3.4.  All you have to do is merge the am64/gcc34 profile into the am64 profile.
> You could do this type of merging with any revision you want to become part of the default profile, and otherwise not change the default profile at all.
> 
> What do you think?

So how does a user know the profile has changed?  What happens to users
using the gcc34 profile?  What would this do to any of the proposed
"stable" portage tree incarnations?

I'm all for a profile for each release which *never* changes.  Additions
can be made as sub-profiles, but a profile never changes.  This way
things act exactly the same every time.  Consistency is a REQUIREMENT
for QA.

I think creating a profile for each release is very simple.  I've
created one myself for 2004.2 and I can tell you that it sure was a hard
3 minutes of my life... *grin*

Having a stable profile is a definite requirement for any stable
project.  Since we've been talking with the stable project guys, I think
we definitely should not be discussing doing the exact opposite of what
is needed to cooperate with them, especially on a separate list which
they might not be subscribed to...
-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

On Mon, 2004-08-16 at 11:10, Chris Gianelloni wrote:
> On Fri, 2004-08-13 at 14:58, William Hubbs wrote:
> > I don't see why we need the yearly refreshes either.
> > 
> > I like the suggestion of making the names more descriptive in stead of using numbers.
> > Fore example, default/linux/am64.
> > Then, you might have default/linux/am64/gcc34.
> > Suppose that you decide to make the default am64 profile use gcc 3.4.  All you have to do is merge the am64/gcc34 profile into the am64 profile.
> > You could do this type of merging with any revision you want to become part of the default profile, and otherwise not change the default profile at all.
> > 
> > What do you think?
> 
> So how does a user know the profile has changed?  What happens to users
> using the gcc34 profile?  What would this do to any of the proposed
> "stable" portage tree incarnations?
> 
> I'm all for a profile for each release which *never* changes.  Additions
> can be made as sub-profiles, but a profile never changes.  This way
> things act exactly the same every time.  Consistency is a REQUIREMENT
> for QA.
> 
> I think creating a profile for each release is very simple.  I've
> created one myself for 2004.2 and I can tell you that it sure was a hard
> 3 minutes of my life... *grin*
> 
> Having a stable profile is a definite requirement for any stable
> project.  Since we've been talking with the stable project guys, I think
> we definitely should not be discussing doing the exact opposite of what
> is needed to cooperate with them, especially on a separate list which
> they might not be subscribed to...

Chris -
I agree on all points. Does the stable team (are they a team) have a ML?

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

On Thu, 2004-08-19 at 11:59, John Davis wrote:
> > Having a stable profile is a definite requirement for any stable
> > project.  Since we've been talking with the stable project guys, I think
> > we definitely should not be discussing doing the exact opposite of what
> > is needed to cooperate with them, especially on a separate list which
> > they might not be subscribed to...
> 
> Chris -
> I agree on all points. Does the stable team (are they a team) have a ML?

Not that I am aware of... All discussions were taking place on -dev as
far as I know.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Ned Ludd]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Thu, 2004-08-19 at 13:16, Chris Gianelloni wrote:
> On Thu, 2004-08-19 at 11:59, John Davis wrote:
> > > Having a stable profile is a definite requirement for any stable
> > > project.  Since we've been talking with the stable project guys, I think
> > > we definitely should not be discussing doing the exact opposite of what
> > > is needed to cooperate with them, especially on a separate list which
> > > they might not be subscribed to...
> > 
> > Chris -
> > I agree on all points. Does the stable team (are they a team) have a ML?
> 
> Not that I am aware of... All discussions were taking place on -dev as
> far as I know.


All of the arch teams are aliases vs mailing lists. If you need 
something to be stabilized on an arch mail arch@g.o if it's all arches
then arch-maintainers@g.o


-- 
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Thu, 2004-08-19 at 14:10, Ned Ludd wrote:
> All of the arch teams are aliases vs mailing lists. If you need 
> something to be stabilized on an arch mail arch@g.o if it's all arches
> then arch-maintainers@g.o

Ehh... what?

"Stable" as in "stable tree", not stable as in stabilize this ebuild on
your arch...

*grin*

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

OK -
I am going to try and make sense of all of the good discussion here by
putting it into a draft proposal. From what I have gleaned off of the
thread, this is the implementation that we are looking for regarding
general profile policy:

Profiles will adhere to the following layout standard:
default-linux/$arch/20xx
default-linux/$arch/20xx-r1
default-linux/$arch/20xx-r2
(and so forth)

Each year, a new profile has to be created (20xx). Each subsequent major
revision to the 20xx profile will be marked as -rx, where x is the
revision number.

The top level arch directory (default-linux/$arch) will contain a
ChangeLog that will serve as a record log for each profile revision and
change.

How does that sound? Am I missing anything?

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Jason Huebel]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

On Friday 20 August 2004 10:09 am, John Davis wrote:
> OK -
> I am going to try and make sense of all of the good discussion here by
> putting it into a draft proposal. From what I have gleaned off of the
> thread, this is the implementation that we are looking for regarding
> general profile policy:
>
> Profiles will adhere to the following layout standard:
> default-linux/$arch/20xx
> default-linux/$arch/20xx-r1
> default-linux/$arch/20xx-r2
> (and so forth)
>
> Each year, a new profile has to be created (20xx). Each subsequent major
> revision to the 20xx profile will be marked as -rx, where x is the
> revision number.
>
> The top level arch directory (default-linux/$arch) will contain a
> ChangeLog that will serve as a record log for each profile revision and
> change.
>
> How does that sound? Am I missing anything?

Looks good to me.  Quick (slightly OT) question:  Is there any limit on the 
directory depth of a cascading profile?

-- 
Jason Huebel
Gentoo/amd64 Strategic Lead
Gentoo Developer Relations/Recruiter

GPG Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9BA9E230

"Do not weep; do not wax indignant. Understand."
Baruch Spinoza (1632 - 1677)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[John Davis]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Fri, 2004-08-20 at 11:40, Jason Huebel wrote:
> On Friday 20 August 2004 10:09 am, John Davis wrote:
> > OK -
> > I am going to try and make sense of all of the good discussion here by
> > putting it into a draft proposal. From what I have gleaned off of the
> > thread, this is the implementation that we are looking for regarding
> > general profile policy:
> >
> > Profiles will adhere to the following layout standard:
> > default-linux/$arch/20xx
> > default-linux/$arch/20xx-r1
> > default-linux/$arch/20xx-r2
> > (and so forth)
> >
> > Each year, a new profile has to be created (20xx). Each subsequent major
> > revision to the 20xx profile will be marked as -rx, where x is the
> > revision number.
> >
> > The top level arch directory (default-linux/$arch) will contain a
> > ChangeLog that will serve as a record log for each profile revision and
> > change.
> >
> > How does that sound? Am I missing anything?
> 
> Looks good to me.  Quick (slightly OT) question:  Is there any limit on the 
> directory depth of a cascading profile?

IIRC, there is not, but you would have to check w/ carpaski to be 100%
sure.

Cheers,
-- 
John Davis
Gentoo Linux Developer
<http://dev.gentoo.org/~zhen>

----
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc>
Fingerprint: 4F9E 41F6 D072 5C1A 636C  2D46 B92C 4823 E281 41BB

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On Thu, 2004-08-12 at 13:36, Paul de Vrieze wrote:
> From what I remember this was not the initial idea. Maybe your position is 
> better, but some discussion might be appropriate. I think it should be done 
> consistently for the different architectures.

I agree with the creation of profiles.  I also think the minimum
versions of packages in the profile should match what is used to build
that release.  This way, we ensure that a "2004.3" machine, especially
one that was upgraded from a previous release, has the same minimal
versions of system packages as our actual release media.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-releng] Re: [gentoo-amd64] Re: 2004.0 Profile Deprecated

[William Hubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Aug 16, 2004 at 11:00:49AM -0400, Chris Gianelloni wrote:
> On Thu, 2004-08-12 at 13:36, Paul de Vrieze wrote:
> > From what I remember this was not the initial idea. Maybe your position is 
> > better, but some discussion might be appropriate. I think it should be done 
> > consistently for the different architectures.
> 
> I agree with the creation of profiles.  I also think the minimum
> versions of packages in the profile should match what is used to build
> that release.  This way, we ensure that a "2004.3" machine, especially
> one that was upgraded from a previous release, has the same minimal
> versions of system packages as our actual release media.

If we are using profiles not only to control which packages are part of the base system, but which versions of the packages are installed, it makes sense to use a different profile for each release.

I also like the idea of a default-linux/<arch>/ChangeLog  or other file that documents what is in each profile.

William

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBITVgblQW9DDEZTgRAsQJAJ9AbxF8CVegQSLz00zNqW8oZbYz7QCeM0yY
4WxAtlbJ/rgnMGc9Kxxguz8=
=sYk6
-----END PGP SIGNATURE-----

--
gentoo-releng@gentoo.org mailing list