| 1 |
Stuart Herbert wrote: |
| 2 |
> On 11/28/06, Chris Gianelloni <wolf31o2@g.o> wrote: |
| 3 |
>> As I have said, I've mentioned several times the idea of doing a |
| 4 |
>> "release tree" to go along with each release. |
| 5 |
> |
| 6 |
> The release tree is not the basis for this. |
| 7 |
> |
| 8 |
> a) Releases (and the releng work that goes into it) are exclusively |
| 9 |
> desktop-oriented. |
| 10 |
|
| 11 |
You make it sound like releng doesn't care at all about non-desktop packages. |
| 12 |
The reason for the "exclusivity" is that the media that's typically built for |
| 13 |
release (GRP, LiveCD) is targetted for the largest audience...desktop users. If |
| 14 |
someone wants to volunteer to create a set of server-related GRP and a server |
| 15 |
LiveCD (as silly as this is for most things), they wouldn't be blocked outright. |
| 16 |
|
| 17 |
> b) Release trees have a nasty habit of picking up last minute changes |
| 18 |
> (such as gcc 4.1) to suit the release, not stability. |
| 19 |
|
| 20 |
Gcc 4.1.1 wasn't a last minute change. The release snapshots are originally |
| 21 |
created a month or more before the actual release. As stuff is stabilized in the |
| 22 |
tree, it's stabilized in the release snapshot as well. During the release cycle, |
| 23 |
we planned for gcc-4.1.1 to be stable by release (at least for x86, amd64, and a |
| 24 |
few other arches). We had it stable in the release snapshot a few weeks before |
| 25 |
the tree did and were testing the crap out of it. |
| 26 |
|
| 27 |
>> No version changes on any packages, except those which are necessary due |
| 28 |
>> to a security violation, or a vulnerable package's dependencies. |
| 29 |
> |
| 30 |
> Tying a minimal-b0rkage tree to the arbitrary schedule of our releases |
| 31 |
> does not serve all of our users. We are back to the same arguments we |
| 32 |
> had when I said that the Seeds project would have to have its own |
| 33 |
> independent release schedules :( |
| 34 |
|
| 35 |
The "release tree" isn't really for minimal breakage. The *real* intent (at |
| 36 |
least from my POV) is to have a non-moving target for vendors to certify their |
| 37 |
software against (wouldn't it be nice for Oracle to be actually supported on |
| 38 |
Gentoo 2007.0 or something like that?), and so admins don't have to do the |
| 39 |
"upgrade dance" once a week or even every day (like I do). |
| 40 |
|
| 41 |
> There¶ little merit in us creating mostly stagnant trees. Other Linux |
| 42 |
> distros are already very good at doing that - far better than we will |
| 43 |
> be at it - because they have advantages such as a paid workforce and |
| 44 |
> more upstream developers on their books. |
| 45 |
|
| 46 |
The "non-stagnant" nature of Gentoo isn't the only reason that people use |
| 47 |
Gentoo. People use Gentoo for the configurability and customizability. As |
| 48 |
someone who admins more than a handful of Gentoo servers, I would absolutely |
| 49 |
*love* the combo of Gentoo's flexibility and a non-moving tree to make upgrades |
| 50 |
easier to deal with. |
| 51 |
|
| 52 |
-- |
| 53 |
Andrew Gaffney http://dev.gentoo.org/~agaffney/ |
| 54 |
Gentoo Linux Developer Installer Project |
| 55 |
Today's lesson in political correctness: "Go asphyxiate on a phallus" |
| 56 |
-- |
| 57 |
gentoo-dev@g.o mailing list |
Archives