OK, a lot of good suggestions and feedback has been offered so far. Thanks to everyone who has participated.
There are two main issues that I want to focus on as possible alternatives for implementing this GLEP. 1) Tarballs for main tree, rsync for security/bugfixes. Several folks have indicated that they feel quarterly updates are too frequent. I personally feel that semi-annual or annual updates are too infrequent and put us at risk of contracting Debian Stable-itis. One alternative I thought of (inspired by a suggestion from Spider) was to create and distribute each quarterly release as a tbz2 and then have a single rsync tree that only contains security updates and bugfixes. These off-cycle changes would, as Spider suggested, be made available via an overlay to avoid corrupting the original tree. The main disadvantages I can see with this are: * Requires portage support to work. (or users will have to do a lot of manual syncing) The original GLEP requires no changes to portage. * Could cause problems if some of the security updates have newer deps that are otherwise not included in the stable tree. I like the idea in principle, however, so I'm curious to hear other people's thoughts as well as their ideas on how to solve the above problems. 2) Using a variable in /etc/make.conf to define update frequencies. I'm not going to summarize this post here because I'd end up leaving something important out. Please see Lisa's original post: http://article.gmane.org/gmane.linux.gentoo.devel/15535/ (side note: I would suggest changing QUARTERLY to MONTHLY to provide more granularity and control to our users) I kind of like this idea, but I really do not like the fact that it doesn't provide any provisions for ensuring ebuilds stay in the tree for a pre-defined period of time. I think this is a critical facet of the GLEP in its current form. If this feature could be included while still keeping a variable-based update frequency as defined above (short of "expect developers to keep track of it") then I think it might be a very viable alternative. So, thoughts, suggestions and comments on the above two alternatives? --kurt
pgp00000.pgp
Description: PGP signature
