Re: [gentoo-dev] New project: Gentoo Seeds

["Stuart Herbert" <stuart.herbert@gmail.com>]

On 9/20/06, Danny van Dyk <kugelfang@gentoo.org> wrote:
> Hi Stuart,
>
> The pages are correct.

Cool.

> He didn't called you a liar.

"You haven't spoken to anyone on the genkernel or catalyst development
teams."  - was in response to me saying that I had.  It's difficult to
interpret that as anything other than calling me a liar.

> However, what you wrote is not quite
> correct. You did talk to 2 people of a whole bunch of people. Neither
> Chris, Lars, Tobias, Andrew nor me knew anything about it.

??  I never said we'd talked to all of you.  I said we'd spoken to
folks on the teams.  What I said is correct.

> If I understand you correctly, you did talk about usage of catalyst,
> but you never informed Releng (as a project) about your intentions.
> And that is what Chris is complaining about. And I agree with him here.

Duly noted.

> Your project sounds really interesting though. I'd like to ask you some
> questions:
>
> * Are you aiming to release vserver images/stage4s together with
>   the "normal" bianual releases?

Sorry, thought I'd covered this earlier (in fact, I know we did).
We're not at the stage of having that answer.  Our focus at the moment
is on getting a working seed defined and tested.

My personal feeling is that seeds are more likely to have a release
schedule based on what their respective $UPSTREAMs are doing.
$UPSTREAMs have their own, individual schedules; I believe that we
need agility to match.  Tying all seeds, irrespective of their
purpose, to the release of our generic release media doesn't seem like
the only answer that will work here.

> * If yes, are you going to use the same snapshots?

We haven't discussed it.  Atm, we're focused on step 1, which is to
get the seeds themselves working from our overlay.

> * If yes, for what arches do you want to release?

That will vary from seed to seed.  There's no automatic need to try
and release each seed on each and every arch that Gentoo as a whole
supports.

The advantage of the meta-package approach is that the bulk of the
value of the seed will be available on any arch where the packages are
keyworded.  We don't need create release media for each and every seed
for each and every arch.  We can deliver that release media for the
seed/arch combos where it makes sense.

A blanket policy of creating release media for every seed on every
arch doesn't seem practical or desirable.

> * How do you want to implement the profiles?

We've only talked about profiles so far for a single seed.  We'd
prefer to inherit from the hardened profile, but we have a number of
questions that we need to answer before we can be sure on that.  We
won't know for certain what the answer is until we've been able to
define and field-test the LAMP Developer Desktop seed.  We don't
expect to deliver that seed until we've put out a LAMP Server seed for
testing and feedback.

> * Re: the meta-ebuilds you'd been talking about in this thread: Have you
>   yet considered to use the profiles' packages file?

Yes.  We think that we'll be making use of that, but we don't want
profiles to replace the meta-ebuilds.  We're going to try both, and
play with that for awhile to see where the balance best lies.

Best regards,
Stu
--
-- 
gentoo-dev@gentoo.org mailing list