| 1 |
On Fri, 2004-04-30 at 18:59, Kurt Lieber wrote: |
| 2 |
|
| 3 |
> I didn't see Bob's original message, but he, Pieter and now myself are |
| 4 |
> going to be saying exactly the same thing. |
| 5 |
> |
| 6 |
> Quarterly releases are too ambitious. We need to slow down. |
| 7 |
> |
| 8 |
> Right now, we're so focused on quarterly releases that we cannot take |
| 9 |
> enough time to develop features that may take longer than three months to |
| 10 |
> code, test and get ready to go. |
| 11 |
> |
| 12 |
> As Pieter pointed out earlier, if we want to release something in July and |
| 13 |
> do proper QA on it ahead of time, we don't really have much time to do any |
| 14 |
> actual *development*. Who cares if we're releasing 4 new versions a year |
| 15 |
> if they're all identical save for minor cosmetic/typo stuff? |
| 16 |
> |
| 17 |
> Quarterly releases need to stop. |
| 18 |
> |
| 19 |
> --kurt |
| 20 |
|
| 21 |
Kurt - |
| 22 |
I've been thinking this over for quite awhile now and have vacilated |
| 23 |
between continuing quarterly releases and moving to something else. |
| 24 |
After much thought (and believe me, there has been a lot - during 2004.0 |
| 25 |
I wanted nothing to do with quarterly releases), I have decided that for |
| 26 |
the immediate future, quarterly releases are the way to go for the |
| 27 |
following reasons: |
| 28 |
|
| 29 |
Gentoo users need and want quarterly releases. If there is a larger time |
| 30 |
gap between releases, they are stuck waiting for updated stages, GRP, |
| 31 |
etc. This leaves them with a longer install (more packages to update |
| 32 |
because the release media is dated) and pretty much negates the effect |
| 33 |
of GRP (who wants to use GRP if the versions are old). |
| 34 |
|
| 35 |
Quarterly releases force good QA througout Gentoo. Building release GRP |
| 36 |
every 3 months or so allows the more critical (kde, gnome, assorted core |
| 37 |
utils, etc) to field more bugs and fix them. If something doesn't work |
| 38 |
for releng, we report it to them and the problem is fixed. I cannot tell |
| 39 |
you how many bugs we have fixed in packages like baselayout because our |
| 40 |
release cycle is so testing intensive. The current release cycle scheme |
| 41 |
is beneficial not just for releng, it helps Gentoo as a whole. |
| 42 |
|
| 43 |
I think where we are getting caught up on quarterly releases is the |
| 44 |
distinction between what kind of features go where. Releng cannot |
| 45 |
support any feature request which does not directly affect our release |
| 46 |
media. Portage feature requests do not belong on the releng feature |
| 47 |
request list because we have no control over them. Does infra take |
| 48 |
feature requests from hardened? Its a similar situation. |
| 49 |
|
| 50 |
The release cycle timeframe is fine, but it may not seem that way |
| 51 |
because a lot of features that do not belong in releng get lumped into |
| 52 |
it. What Gentoo really needs is two feature request lists - one for |
| 53 |
Gentoo as a whole, perhaps using the release cycle as a guideline |
| 54 |
(implement GPG signing by 2005.1), but not putting other subproject's |
| 55 |
duties onto releng, and one for releng (which would deal with release |
| 56 |
specific features, such as adding in a log for dmesg or better labeling |
| 57 |
our LiveCDs). If we have this distinction I believe that a lot of these |
| 58 |
concerns will go away. |
| 59 |
|
| 60 |
Cheers, |
| 61 |
//zhen |
| 62 |
-- |
| 63 |
John Davis |
| 64 |
Gentoo Linux Developer |
| 65 |
<http://dev.gentoo.org/~zhen> |
| 66 |
|
| 67 |
---- |
| 68 |
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc> |
| 69 |
Fingerprint: 2364 71BD 4BC2 705D F338 FF70 6650 1235 1946 2D47 |
Archives