| 1 |
On Tue, 2008-07-29 at 04:16 +0200, lurker wrote: |
| 2 |
> On 28/07/08 18:18, Chris Gianelloni wrote: |
| 3 |
> > Just a little FYI for everybody on the list... |
| 4 |
> > |
| 5 |
> > I've gone and forked most of the Release Engineering tools. I no longer |
| 6 |
> > plan on maintaining the "Gentoo" versions of catalyst, genkernel, |
| 7 |
> > hwdata, or livecd-tools. Instead, I am working on these projects under |
| 8 |
> > my own domain and will be releasing them as "standalone" applications, |
| 9 |
> > not under the Gentoo moniker. Now, these projects always have been |
| 10 |
> > "Gentoo Hosted Projects" and not really owned by the Gentoo project, but |
| 11 |
> > continued issues from other developers has proven that many don't |
| 12 |
> > understand this case. As such, it was simply easier to break away from |
| 13 |
> > the main project. This also allows us greater flexibility in making |
| 14 |
> > changes that would otherwise not be accepted within Gentoo. All of the |
| 15 |
> > current maintainers of these forks will be working on them in their new |
| 16 |
> > homes, making the Gentoo-hosted versions essentially dead. |
| 17 |
> |
| 18 |
> Interesting development. Can we be confident that the new independent |
| 19 |
> catalyst will not break the current interfaces (ignoring trivial |
| 20 |
> changes) and the use of portage? More to the point: what does this mean |
| 21 |
> for existing catalyst projects that are using portage and intend to stay |
| 22 |
> with it? |
| 23 |
|
| 24 |
There will be some disruptive changes to the spec interface. For one, |
| 25 |
I've removed all of the deprecated spec key support, so if your specs |
| 26 |
were based on catalyst 1.x specs, they won't work anymore (without |
| 27 |
modification.) |
| 28 |
|
| 29 |
As Andrew said, we don't intend on breaking anything, except where |
| 30 |
absolutely necessary. We're trying to focus on making catalyst easier |
| 31 |
to use, yet still more powerful. One example of an incompatible change |
| 32 |
that we're *definitely* going to adopt: compilation of bootloader. |
| 33 |
Since this obsoletes the "cdtar" key, that option won't be valid in |
| 34 |
newer catalyst versions. This will be the general scope of |
| 35 |
interface-level changes, so people relying on catalyst, such as myself, |
| 36 |
have no need to worry. Things will stay similar-enough that transition |
| 37 |
from current catalyst to the new one will be rather minor. |
| 38 |
|
| 39 |
-- |
| 40 |
Chris Gianelloni |
| 41 |
Release Engineering Strategic Lead |
| 42 |
Games Developer |
Archives