Where we are and where do we what to go?

[Dan Horák]

Thorsten Leemhuis píše v Út 10. 02. 2009 v 10:14 +0100:
> On 10.02.2009 09:57, Dan Horák wrote:
> > Thorsten Leemhuis píše v Po 09. 02. 2009 v 19:58 +0100:
> >> On 09.02.2009 14:28, Dan Horák wrote:
> >>> Thorsten Leemhuis píše v Ne 08. 02. 2009 v 10:06 +0100:
> >>>> On 04.02.2009 14:24, Rex Dieter wrote:
> >>>>> Thorsten Leemhuis wrote:
> >>>>>> On 04.02.2009 14:00, Rex Dieter wrote:
> >>>>>>> Andrea Musuruane wrote:
> >>>>>>> [...]
> >>>>>>> In the meantime, I'll go adjust the wiki to move kde-redhat to the 
> >>>>>>> "compatible" section. :)
> >>>>>> If RPM Fusion would have one big and/or multiple dedicated experimental 
> >>>>>> repos, would kde-redhat then be interested into "merging" into RPM 
> >>>>>> Fusion? 
> >>>>> yes!
> >>>> I'd like that to happen. What others think of the idea to start a 
> >>>> experimental area and do the first steps with kde-redhat like repos?
> >>> I agree and would like join with some of my stuff.
> >> Hmmm. kde-redhat is something special, so a dedicated repo for it makes 
> >> a lot of sense afaics.
> >> But do you need to have your own dedicated experimental repo. Might a 
> >> general experimental repo be a better solution? Not sure myself, just 
> >> want to hear options...
> > 
> > Oh, I was thinking that we are going to offer a merger for the personal
> > or highly specialized repos into one experimental repo (if possible)
> > that will use RPM Fusion's infrastructure.
> > [...]
> > When there should be multiple repos, then I would prefer to divide them
> > by relation to Fedora/RPM Fusion (eg. experimental, backports) rather
> > then by area (kde, mono, math, ...)
> 
> A dedicated "math" repo like really is not needed -- those packages are 
> likely more suitable for a general experimental and/or staging repo. But 
> I guess some sort of spits by area will be needed -- I guess that (for 
> example) the kde-redhat users likely don't want to get highly 
> experimental graphics drivers from the same repo when they run yum-update.
> 
> Or how would you solve that? Excludes and includepkgs statements in the 
> repo files are likely way to complicated...

I should have known it will be complicated, but let's try to categorize
the possible stuff:

- new packages => no conflicts with Fedora/RPM Fusion => 2 repos (stable
+ testing), stable enabled by default

- existing packages
	- experimental
		- examples: codeblocks
	- backports
		- examples:
	- forwardports (new stable versions from Fedora into EL)
		- examples: zabbix (no rebase 1.4->1.6 planned due DB
		changes etc, but some users would appreciate to have
		the 1.6)

		- one repo for each category, disabled by default, user
		must manually enable the repo and pick the package he
		want to install or update

	- special cases like kde-redhat - 2 repos (again stable +
		 testing) per case, stable enabled by default

Does this sound feasible?


		Dan