| 1 |
I just read the Release Engineering document on the front page of |
| 2 |
gentoo.org and I am very pleased. Everyone involved, I applaud you all |
| 3 |
- this looks like an excellent process to add to Gentoo and it looks to |
| 4 |
be incorporating many of the things I've enjoyed from the FreeBSD |
| 5 |
project. |
| 6 |
|
| 7 |
In the past, devs have bulked at making actual version releases, saying |
| 8 |
that people should just emerge sync and they'll be at the latest 1.4 or |
| 9 |
what have you. Maybe they were afraid of falling into the pit of |
| 10 |
molasses that Debian seems to be perpetually trapped in. The scheme of |
| 11 |
4 mandatory releases per year looks like an excellent compromise, |
| 12 |
provided QA is still there. So you'll still have fresh releases with |
| 13 |
decent QA to boot. |
| 14 |
|
| 15 |
A couple things: |
| 16 |
Versions named by year? Thats always been a pet peeve I had with other |
| 17 |
programs... is this now set in stone for Gentoo? |
| 18 |
|
| 19 |
Are prior versions going to be kept available on rsync mirrors, similar |
| 20 |
to how one might leave a FreeBSD box cvsup'ing against RELENG_4_8 rather |
| 21 |
than -CURRENT or -STABLE? Furthermore, if prior versions would be left |
| 22 |
up on the mirrors, how practical would it be to maybe have the GLSA |
| 23 |
people backporting the GLSAs? The BSDs do this, but obviously you can't |
| 24 |
keep it up for ever... the OpenBSD people only do it for the last 2 |
| 25 |
versions + the current one, don't know where the FreeBSD people draw the |
| 26 |
line. |
| 27 |
|
| 28 |
Again though, Kudos. I'm feeling some renewed enthusiasm for Gentoo |
| 29 |
stirring in me now. |
| 30 |
|
| 31 |
|
| 32 |
|
| 33 |
(If this was already discussed in the list, forgive my lameness because |
| 34 |
I missed it) |
| 35 |
|
| 36 |
|
| 37 |
-- |
| 38 |
gentoo-dev@g.o mailing list |
Archives