On Tue, 2004-02-03 at 09:55, Kurt Lieber wrote: > 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.
I still like the idea of separate rsync branches. gentoo-2004.0-stable and gentoo-2004.0-updates, both taken via rsync with -stable being static per release and -updates being dynamic and an overlay to ensure it always overrides the -stable unless a user emerges a =cat/ver combo from stable. > 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. Honestly, I don't think it matters nearly as much as getting a tree going. I would like to see ANY tree being done ASAP, we can increase the frequency of the updates as we get up-to-speed on the branch. > 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. Dual portage trees requires no portage changes as portage supports multiple overlays now. > * Could cause problems if some of the security updates have newer deps that > are otherwise not included in the stable tree. Those would also be updated in -updates, as needed. > 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 like this idea, in a sense. I think having a defined VERSION variable (or some other name) to determine the release to update against would work. > 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. Having separate trees solves this, simply do not remove ANYTHING from the tree until it is time to remove the entire tree. The portage tree itself, even if duplicated a few times, such as 2004.0 2004.1, etc still is not very large. I'm curious to hear what everyone has to say about my ideas, but I would definitely help out in any way I can no matter what is decided. -- Chris Gianelloni Developer, Gentoo Linux Games Team Is your power animal a pengiun?
signature.asc
Description: This is a digitally signed message part
