Re: [gentoo-dev] Round 2: GLEP 19 -- Gentoo Stable Portage Tree

[Chris Gianelloni]

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?