| 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 |
Archives