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