1 |
this sounds good.. and the tree specification is builtin :P |
2 |
|
3 |
SYNC="rsync://mirrors.gentoo.org/gentoo-stable" |
4 |
|
5 |
SYNC="rsync://mirrors.gentoo.org/gentoo-current" |
6 |
|
7 |
I would be willing to offer time on a project like this ( part time |
8 |
unfortunately ) considering i am also already maintaining my own |
9 |
version of the portage tree for stability reasons. |
10 |
|
11 |
|
12 |
On Wed, 2003-06-25 at 14:38, Matt Thrailkill wrote: |
13 |
> Its looking like this is the most practical way of going about achieving |
14 |
> the stricter version control I and others are thinking about. And its |
15 |
> not too much work... but its alot of wasted effort when you have a bunch |
16 |
> of people doing it for themselves individually. |
17 |
> |
18 |
> Maybe it would be a good idea to have a team/project/whatever who's |
19 |
> responsibility is to create and maintain snapshots of the Portage tree |
20 |
> at different times, and let them take care of assigning Gentoo version |
21 |
> numbers and to those snapshots? Meanwhile the rest of the Gentoo team |
22 |
> can just keep moving forward with the ever changing metadistribution and |
23 |
> not have to worry too much about distilling it for releases so much as |
24 |
> doing good work and making cool stuff. |
25 |
> |
26 |
> Maybe such a project could be a sub-project of stable.gentoo.org, since |
27 |
> they seem to be collecting alot of information about stability of things |
28 |
> in Portage as it is. |
29 |
> |
30 |
> I think what you'd end up with would be most of the people working on |
31 |
> advancing Gentoo now would be working on what is analagous to -CURRENT |
32 |
> in FreeBSD, and then this other group of people would be like the |
33 |
> Release Engineering team (looking at drobbins proposal, he already |
34 |
> mentioned one), deciding when -CURRENT was ripe for splitting off and |
35 |
> stabilizing into a release with such and such goals and featureset. |
36 |
> |
37 |
> At the least regimented level, it'd be a centralized place for people |
38 |
> like Stuart and I to go and pick a static Portage tree to track for our |
39 |
> servers. Let the people at that centralized place merge the security |
40 |
> updates and bugfixes into the static trees as they see fit. And it |
41 |
> shouldn't prove much hindrance to the rest of people working on |
42 |
> advancing the bleeding edge, besides maybe modifications to Portage so |
43 |
> it has the tree selection abilities built in. |
44 |
> |
45 |
> On Wed, 25 Jun 2003 21:01:00 +0200 |
46 |
> Paul de Vrieze <pauldv@g.o> wrote: |
47 |
> |
48 |
> > In such a case you might want to run your own cvs ( or subversion) |
49 |
> > tree of "sanctioned ebuilds", and instead of emerge sync run cvs |
50 |
> > update on the slaves. You then can copy only interesting ebuilds to |
51 |
> > the cvs tree, and only wanted changes. Of course this is more work, |
52 |
> > but if it should not be too hard to create a "custom tree" based on |
53 |
> > the ebuilds that are currently installed. You could put that tree, |
54 |
> > with the required distfiles on a custom gentoo bootcd, which you could |
55 |
> > use to install all clients. |
56 |
> > |
57 |
> > Paul |
58 |
> |
59 |
> -- |
60 |
> gentoo-dev@g.o mailing list |