1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
K, so I've been sitting back watching this thread, formulating my evil |
5 |
response. :-) So here goes: |
6 |
|
7 |
LiveCDs: |
8 |
- --- |
9 |
I like the idea of moving to a 4 month release cycle in 2005. |
10 |
|
11 |
However, I think the quarterly release cycle is healthly for the amd64 |
12 |
arch right now because we are working to refine our LiveCDs for various |
13 |
hardware. It important that we have more frequent updates to our |
14 |
LiveCDs because amd64 hardware is still a moving target. For instance, |
15 |
it's only been in the past few months that amd64 laptops have come on to |
16 |
the market in any volume. So we're working on refining the available |
17 |
kernels to support them. |
18 |
|
19 |
|
20 |
GRP: |
21 |
- --- |
22 |
Face it, devs hate having to build GRP because it's the longest part of |
23 |
our release process. But even I've used the GRP packages a number of |
24 |
times so I could quickly build a Gentoo box on slow hardware. I really |
25 |
would hate to have to build KDE or GNOME on a P3/550. :-) |
26 |
|
27 |
GRP is good for users, but time consuming for releng. Like it or not, |
28 |
it's a necessary evil. |
29 |
|
30 |
|
31 |
Feature Requests: |
32 |
- --- |
33 |
Releases aren't always about new features. I think that we should |
34 |
consider having one or two releases a year that include significant new |
35 |
features, but the other releases are maintenance. It seems to me that a |
36 |
.0 release is a feature release, while >=.1 is maintenance. Or am I just |
37 |
naive about what version numbers should really mean? ;-) |
38 |
|
39 |
I would even be cool with having .0 and .2 as feature releases, like |
40 |
jforman mentioned. But I think it's overly ambitious to include some |
41 |
new whizbang feature in every release. |
42 |
|
43 |
|
44 |
LiveCDs: |
45 |
- --- |
46 |
Could the LiveCD's be broken up differently, making them easier to |
47 |
maintain? What if there was one bootable CD -- bootCD -- rather than |
48 |
two -- universal and minimal? That bootCD could be ejected and the user |
49 |
could insert the appropriate stageCD. The stageCD's wouldn't need to be |
50 |
bootable. So, you could have: |
51 |
|
52 |
bootCD - bootable, docs |
53 |
stage1CD - stage1 tarball, distfiles |
54 |
stage2CD - stage2 tarball, distfiles |
55 |
stage3CD - stage3 tarball, distfiles |
56 |
packageCD - packages |
57 |
|
58 |
Don't know if this idea has any merit, but... |
59 |
|
60 |
|
61 |
Other Thoughts: |
62 |
- --- |
63 |
catalyst docs need attention. 2004.1 was my first release and it was |
64 |
tough. zhen and beejay were a HUGE help, but I found there were times |
65 |
when my CPU sat idle because I didn't know what to do next. So I had to |
66 |
wait around in the -releng channel for help. I understand that everyone |
67 |
is busy and can't cater to my schedule (don't I wish :-), but if there |
68 |
were some more comprehensive docs (or even some type of checklist) we |
69 |
would all be better off. |
70 |
|
71 |
I've got some handwritten notes on the steps for building a release. I |
72 |
guess I could XML-ify them if they would be useful to others. |
73 |
|
74 |
|
75 |
That's about all I can think of for now. It's been a long day and I have |
76 |
a nice bottle of cognac calling my name... |
77 |
|
78 |
"Jason... Drink me..." |
79 |
/me wanders off... |
80 |
|
81 |
|
82 |
Jason Huebel |
83 |
Gentoo/amd64 Lead |
84 |
-----BEGIN PGP SIGNATURE----- |
85 |
Version: GnuPG v1.2.4 (GNU/Linux) |
86 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
87 |
|
88 |
iD8DBQFAlx/bbNgbbJup4jARAuveAJ4oAq3jDGAaDFVZF1Ag0mhe+GMYgwCdHsB1 |
89 |
Dlb7V/+VtgM0+eCzIQzCefo= |
90 |
=H34G |
91 |
-----END PGP SIGNATURE----- |
92 |
|
93 |
-- |
94 |
gentoo-releng@g.o mailing list |