| 1 |
On Fri, 2004-05-14 at 14:01, Grant Goodyear wrote: |
| 2 |
> Dear all, |
| 3 |
> I would like to get a discussion rolling about what, exactly, |
| 4 |
> constitutes a Gentoo release, and what we want to accomplish with any |
| 5 |
> given release. I'm forwarding (with Aron's permission) an e-mail that |
| 6 |
> agriffis sent to -releng describing his view about what our release |
| 7 |
> process currently is. I believe that this description does describe |
| 8 |
> the current process reasonably well, but perhaps some may disagree. |
| 9 |
> More important, is this process what we _want_ our release process to |
| 10 |
> be? Gentoo "releases" are different from those of any other |
| 11 |
> distribution, inasmuch as the "version" of Gentoo that a user is |
| 12 |
> running (meaning what collection of packages are on the user's |
| 13 |
> machine) depends on what *hour* Gentoo was installed, so from a |
| 14 |
> technical standpoint the "release" has more to do with the |
| 15 |
> installation medium than anything else. At the same time, it is |
| 16 |
> important to recognize that releases also serve a public-relations |
| 17 |
> purpose. Take a look at OpenBSD's recent release, |
| 18 |
> http://www.openbsd.org/35.html. The "What's New" section of that page |
| 19 |
> is fairly extensive, and distrowatch and other news sites have |
| 20 |
> provided OpenBSD with a fair amount of coverage about their new release. |
| 21 |
> Even if we maintain a calendar-based release system, should we also |
| 22 |
> be striving to make releases goal-oriented as well? If so, how do we |
| 23 |
> go about doing so? |
| 24 |
> |
| 25 |
> Some thoughts, |
| 26 |
> g2boojum |
| 27 |
> |
| 28 |
|
| 29 |
Grant (and all) - |
| 30 |
This is one of those questions that we (releng) have been working on as |
| 31 |
of late :) At the last releng meeting, we brought this up and had some |
| 32 |
pretty decent discussion about it. |
| 33 |
|
| 34 |
Releng came to a consensus of what we believe a Gentoo release is. |
| 35 |
Basically, it is not too far from what you are talking about. The way |
| 36 |
Gentoo is setup it is pretty natural to release the way that we do. |
| 37 |
Since Gentoo users are always up-to-date, they really have no need for |
| 38 |
upgrade type installation media. The media that matters to them is |
| 39 |
initial install media, such as LiveCDs, stages, and GRP. Building stages |
| 40 |
and GRP on a quarterly basis keeps the media up-to-date and users happy. |
| 41 |
LiveCDs don't necessarily need to be built quarterly (once we stabilize |
| 42 |
them), and that is an option that we are exploring. |
| 43 |
|
| 44 |
Now, where does this leave features? Aron had a good point - why do we |
| 45 |
have features for 2004.2? What releng decided is that that releng |
| 46 |
features affect releng release media. Looking at the finalized release |
| 47 |
feature list for .2 (http://dev.gentoo.org/~zhen/2004.2_request.txt) you |
| 48 |
will see that all of the features are media-centric. Releng decided that |
| 49 |
it would not be fair for us to dictate deadlines for features to other |
| 50 |
projects besides our own. Releng dictating a release deadline to the |
| 51 |
Portage team for example would be ridiculous because we are so |
| 52 |
unattached from their development process. Portage is an integral part |
| 53 |
of Gentoo, but releng really shouldn't have say over how they manage |
| 54 |
their own project (and part of management is features). Also, this gives |
| 55 |
releng the time and manpower to explore other cool things such as X |
| 56 |
LiveCDs, GameCDs, and other neat things (wireless router livecds?). |
| 57 |
|
| 58 |
This doesn't mean that those projects can't coincide their features with |
| 59 |
our release schedule. If they want to, that is great because we can use |
| 60 |
it as a marketing point :) As long as they can have the feature done on |
| 61 |
time for release, I am game, and would be more than happy to give it as |
| 62 |
much PR as we can. |
| 63 |
|
| 64 |
So basically, we can synthesize goal oriented releases and time based |
| 65 |
releases to fit Gentoo. I don't think that using one or the other |
| 66 |
exclusively would really do us much good. Perhaps a good addition would |
| 67 |
be a Product Manager, like klieber brought up. This position (which |
| 68 |
would not be part of releng but rather above, part of metastructure |
| 69 |
perhaps?) could manage non-releng feature coincidence with our release |
| 70 |
schedule. |
| 71 |
|
| 72 |
Give releng some time and we will get there. A discussion like this one |
| 73 |
is a step in the right direction though :) Thanks for listening ;) |
| 74 |
|
| 75 |
Cheers, |
| 76 |
//zhen |
| 77 |
|
| 78 |
BTW - All of this is being presented to managers on Monday ;) |
| 79 |
|
| 80 |
-- |
| 81 |
John Davis |
| 82 |
Gentoo Linux Developer |
| 83 |
<http://dev.gentoo.org/~zhen> |
| 84 |
|
| 85 |
---- |
| 86 |
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc> |
| 87 |
Fingerprint: 2364 71BD 4BC2 705D F338 FF70 6650 1235 1946 2D47 |
Archives