Gentoo Archives: gentoo-dev

From: Kurt Lieber <klieber@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Round 2: GLEP 19 -- Gentoo Stable Portage Tree
Date: Tue, 03 Feb 2004 15:13:35
Message-Id: 20040203145515.GY22870@mail.lieber.org
1 OK, a lot of good suggestions and feedback has been offered so far. Thanks
2 to everyone who has participated.
3
4 There are two main issues that I want to focus on as possible alternatives
5 for implementing this GLEP.
6
7 1) Tarballs for main tree, rsync for security/bugfixes.
8
9 Several folks have indicated that they feel quarterly updates are too
10 frequent. I personally feel that semi-annual or annual updates are too
11 infrequent and put us at risk of contracting Debian Stable-itis.
12
13 One alternative I thought of (inspired by a suggestion from Spider) was to
14 create and distribute each quarterly release as a tbz2 and then have a
15 single rsync tree that only contains security updates and bugfixes. These
16 off-cycle changes would, as Spider suggested, be made available via an
17 overlay to avoid corrupting the original tree.
18
19 The main disadvantages I can see with this are:
20
21 * Requires portage support to work. (or users will have to do a lot
22 of manual syncing) The original GLEP requires no changes to portage.
23 * Could cause problems if some of the security updates have newer deps that
24 are otherwise not included in the stable tree.
25
26 I like the idea in principle, however, so I'm curious to hear other
27 people's thoughts as well as their ideas on how to solve the above
28 problems.
29
30 2) Using a variable in /etc/make.conf to define update frequencies.
31
32 I'm not going to summarize this post here because I'd end up leaving
33 something important out. Please see Lisa's original post:
34
35 http://article.gmane.org/gmane.linux.gentoo.devel/15535/
36
37 (side note: I would suggest changing QUARTERLY to MONTHLY to provide more
38 granularity and control to our users)
39
40 I kind of like this idea, but I really do not like the fact that it doesn't
41 provide any provisions for ensuring ebuilds stay in the tree for a
42 pre-defined period of time. I think this is a critical facet of the GLEP
43 in its current form. If this feature could be included while still keeping
44 a variable-based update frequency as defined above (short of "expect
45 developers to keep track of it") then I think it might be a very viable
46 alternative.
47
48
49 So, thoughts, suggestions and comments on the above two alternatives?
50
51 --kurt

Replies