Where we are and where do we what to go?

[Thorsten Leemhuis]

On 10.02.2009 11:48, Dan Horák wrote:
> 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:
> [...]
>>> 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.
>> repo files are likely way to complicated...
> I should have known it will be complicated, but let's try to categorize
> the possible stuff:

Not sure yet if I like that scheme. But I'm not even sure if I fully 
understand it yet.

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

You mean the normal free and nonfree repos we already have?

Side note: Should we split free and nonfree for those experimental areas 
as well? I tend to say "no", as that might complicate things to much 
(CVS, pushing, configuration for users, yum overhead, ...) .

> - existing packages
> 	- experimental
> 		- examples: codeblocks

/me tries to get the example

Ahh, codeblocks is one of you Fedora packages!

/me thinks he got it now

> 	- 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

Does the user actually care if it's a back- or forwardport? I'd say "not 
really".

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

Rex, would you actually need "stable" and "testing" repos or could this 
work without "testing"?

> Does this sound feasible?

As I said, not sure yet. I'll think about it for a while longer ;-)

Cu
knurd