| 1 |
On Mon, Aug 09, 2004 at 10:21:09AM -0400 or thereabouts, Chris Gianelloni wrote: |
| 2 |
> Fork into a completely new module. |
| 3 |
|
| 4 |
I don't think this is a very good idea for reasons that I'll discuss below. |
| 5 |
|
| 6 |
> Take any and all ebuilds which are marked as stable for a particular |
| 7 |
> arch, remove any ~arch keywords, and split it to a gentoo-$version |
| 8 |
> module. |
| 9 |
|
| 10 |
Agreed, though I don't see a real need to remove ~arch ebuilds. |
| 11 |
|
| 12 |
> Since it is a separate module, the ebuilds will always be |
| 13 |
> there. Since it was taken from the release snapshot for each arch, |
| 14 |
> it'll also match what is done on the release media, making bug hunting |
| 15 |
> even easier. |
| 16 |
|
| 17 |
[side note] the releases of the tree are not tied to the releases of our |
| 18 |
liveCD/package sets.[/side note] |
| 19 |
|
| 20 |
> Here, we're using the SYNC variable to control the tree, rather than a |
| 21 |
> profile. This means we can support multiple profiles on the same tree |
| 22 |
> easily, and also keeps ebuilds around for as long as we keep the tree |
| 23 |
> around. |
| 24 |
|
| 25 |
One think that I think *everyone* agrees on is that any stable tree needs |
| 26 |
to be regularly updated with security fixes. With this in mind, I'm |
| 27 |
concerned with trying to maintain multiple separate SYNC modules. We'd |
| 28 |
have to upgrade each one with every GLSA, thus doubling or tripling the |
| 29 |
amount of CVS work needed each time. |
| 30 |
|
| 31 |
--kurt |
Archives