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 |