Hi Troy,

On Jun 7, 2010, at 20:15 , Troy Dawson wrote:

> Hello,
> With the RHEL6 beta out, and SL 5.5 released, it's time to really start planning for SL6.

right.

> There are a few idea's that would be good to be discussed before we
> charge forward to implement them.
> 
> *Sites - Customized SL releases
> In the past, we have always put patches into anaconda (the installer) so
> that people and groups can more easily create a custom release.
> We were thinking of not changing the installer at all, but instead
> implement revisor, and it's friends, to create custom sites, in the same
> way that Fedora creates their custom spins.
> - This would be less work on our part
> - Documentation should be better since we would mainly be using Fedora's
> - The technique could be transfered to CentOS based distributions.

I'm very much in favour of the idea not to change the installer. The SL "sites" concept is really neat, but IMHO it hasn't worked out and today is mostly redundant. The possibility to add yum repos during installation now provides for almost all the features sites had, and driver/update "disks" provide the rest.

> *Yum - autoupdate
> How do we want to do that?
> - Continue with my script ?
> - Use yum-cron ?
> - have several things available ?

While all these are fine work, and are very useful for the casual end-user-managed system, what I really like about SL is the ability to easily get rid of them altogether and replace them with something more suitable in a production environment with hundreds of systems. Sorry, that simply is my use case.

> *Kernel-modules
> They are a necessary evil.  How should we handle them on SL6

Very good question. Unfortunately, it's hard to answer right now. The 'kernel-module-' way has worked well for us - some overhead, but no ugly surprises. KABI-dependent modules are certainly an attractive alternative. Alas, the whitelisted ABI was much too restricted in the past to be useful for our purposes (not usable for the nvidia driver nor the AFS client, to give just two examples). It seems that's being worked on, and circumstances are likely to change before RHEL6 GA. My current proposal would be to stay with kernel-module- except where KABI-aware kmods work cleanly.

> *Security - Bugs - Enhancement Updates
> Do we want everything separate still?
> Do we want everything in one big yum repository with them labeled
> correctly as Security, Bugs, and Enhancements?
> If we had them in one big repository, we would have to label them as
> security, bugs, enhansements, and them make sure we used the
> yum-security plugin.

I really like the way you're currently handling this. Unless there's a pressing need to, please don't change it.

> *Yum Repositories
> What should we have for default?
> Should we still have "contrib"?
> Should we add "development"?
> Should we have yum-conf-epel?  Or should that be a default repository?

I'm not sure "contrib" has worked well. It could be dropped if it helps.

"Development" seems like a rename of "testing" to me?

EPEL is important, and our preferred source for add-ons when required. But I don't think it should be a default repo.

> *JAVA
> I propose we don't add Sun's (Oracle's) java.

I concur.

> *What should we add to SL6
> At the last Hepix meeting one of the discussions was that many
> scientists are adding their packages to EPEL.  They would like it if
> packages that are in EPEL stay just in EPEL and not go into SL unless
> there is a good reason for it.
> A good reason would be that it is needed during the install.
> I like this idea and would like to adopt it.
> This would mean that we would take out several packages that have
> traditionally been in earlier SL releases, but I think it will make
> things better and more consistent in the long run.
> This way scientists would be able to know they are getting the same
> packages whether they are running SL, RHEL or CentOS.
> Thoughts on this proposal?

Yes. Let's keep it to a minimum, and restrict add-ons to packages not available from EPEL nor likely to become so. This still leaves valuable add-ons for SL as compared to RHEL or CentOS.

On the downside, SL has been ahead of EPEL by many months during past releases, hence it may be hard to judge what might be in EPEL a while after the release of SL6.0. Reserving the right to remove such add-ons with the SL6.1 release in the 6.0 relnotes may be a good idea?

Cheers,
	Stephan

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany