Just a little FYI for everybody on the list...

I've gone and forked most of the Release Engineering tools. I no longer
plan on maintaining the "Gentoo" versions of catalyst, genkernel,
hwdata, or livecd-tools. Instead, I am working on these projects under
my own domain and will be releasing them as "standalone" applications,
not under the Gentoo moniker. Now, these projects always have been
"Gentoo Hosted Projects" and not really owned by the Gentoo project, but
continued issues from other developers has proven that many don't
understand this case. As such, it was simply easier to break away from
the main project. This also allows us greater flexibility in making
changes that would otherwise not be accepted within Gentoo. All of the
current maintainers of these forks will be working on them in their new
homes, making the Gentoo-hosted versions essentially dead.

The projects are being hosted on wolf31o2.org and are currently being
hosted in a set of private git repositories. I'll announce here when I
get a chance to get the public repositories online. When I do, I'll
change the "catalyst-9999" and "genkernel-9999" ebuilds to reflect the
new repository locations.

I'll keep using this mailing list, for the time being, for my forks of
these projects. I will be setting up my own lists, but see no real need
to move in a rush, seeing as how low-volume this list usually is.

Bug reports can be sent to this list or reported to Gentoo's bugzilla,
but I won't have permanent access to that location, since I am retiring
as a Gentoo developer.

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer

On 28/07/08 18:18, Chris Gianelloni wrote:
> Just a little FYI for everybody on the list...
>
> I've gone and forked most of the Release Engineering tools. I no longer
> plan on maintaining the "Gentoo" versions of catalyst, genkernel,
> hwdata, or livecd-tools. Instead, I am working on these projects under
> my own domain and will be releasing them as "standalone" applications,
> not under the Gentoo moniker. Now, these projects always have been
> "Gentoo Hosted Projects" and not really owned by the Gentoo project, but
> continued issues from other developers has proven that many don't
> understand this case. As such, it was simply easier to break away from
> the main project. This also allows us greater flexibility in making
> changes that would otherwise not be accepted within Gentoo. All of the
> current maintainers of these forks will be working on them in their new
> homes, making the Gentoo-hosted versions essentially dead.

Interesting development. Can we be confident that the new independent
catalyst will not break the current interfaces (ignoring trivial
changes) and the use of portage? More to the point: what does this mean
for existing catalyst projects that are using portage and intend to stay
with it?

lurker wrote:

On 28/07/08 18:18, Chris Gianelloni wrote:

Just a little FYI for everybody on the list...

I've gone and forked most of the Release Engineering tools. I no longer
plan on maintaining the "Gentoo" versions of catalyst, genkernel,
hwdata, or livecd-tools. Instead, I am working on these projects under
my own domain and will be releasing them as "standalone" applications,
not under the Gentoo moniker. Now, these projects always have been
"Gentoo Hosted Projects" and not really owned by the Gentoo project, but
continued issues from other developers has proven that many don't
understand this case. As such, it was simply easier to break away from
the main project. This also allows us greater flexibility in making
changes that would otherwise not be accepted within Gentoo. All of the
current maintainers of these forks will be working on them in their new
homes, making the Gentoo-hosted versions essentially dead.


Interesting development. Can we be confident that the new independent
catalyst will not break the current interfaces (ignoring trivial
changes) and the use of portage? More to the point: what does this mean
for existing catalyst projects that are using portage and intend to stay
with it?


No, you cannot be confident of that. You never have been able to. We tend to
"break" things all the time. However, we do our best not to


Catalyst will always be compatible with portage (at least, we won't
intentionally break it). We'll also be adding support for pkgcore and perhaps
focusing more on that particular PM in the future.


--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator

On Tue, 2008-07-29 at 04:16 +0200, lurker wrote:
> On 28/07/08 18:18, Chris Gianelloni wrote:
> > Just a little FYI for everybody on the list...
> >
> > I've gone and forked most of the Release Engineering tools. I no longer
> > plan on maintaining the "Gentoo" versions of catalyst, genkernel,
> > hwdata, or livecd-tools. Instead, I am working on these projects under
> > my own domain and will be releasing them as "standalone" applications,
> > not under the Gentoo moniker. Now, these projects always have been
> > "Gentoo Hosted Projects" and not really owned by the Gentoo project, but
> > continued issues from other developers has proven that many don't
> > understand this case. As such, it was simply easier to break away from
> > the main project. This also allows us greater flexibility in making
> > changes that would otherwise not be accepted within Gentoo. All of the
> > current maintainers of these forks will be working on them in their new
> > homes, making the Gentoo-hosted versions essentially dead.
>
> Interesting development. Can we be confident that the new independent
> catalyst will not break the current interfaces (ignoring trivial
> changes) and the use of portage? More to the point: what does this mean
> for existing catalyst projects that are using portage and intend to stay
> with it?

There will be some disruptive changes to the spec interface. For one,
I've removed all of the deprecated spec key support, so if your specs
were based on catalyst 1.x specs, they won't work anymore (without
modification.)

As Andrew said, we don't intend on breaking anything, except where
absolutely necessary. We're trying to focus on making catalyst easier
to use, yet still more powerful. One example of an incompatible change
that we're *definitely* going to adopt: compilation of bootloader.
Since this obsoletes the "cdtar" key, that option won't be valid in
newer catalyst versions. This will be the general scope of
interface-level changes, so people relying on catalyst, such as myself,
have no need to worry. Things will stay similar-enough that transition
from current catalyst to the new one will be rather minor.

--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer