Where we are and where do we what to go?

[Dan Horák]

Thorsten Leemhuis píše v Út 10. 02. 2009 v 20:43 +0100:
> 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.

No problem, it is a discussion.

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

This should be a place for packages that the submitter has created, can
update them sometimes, but he is not willing to submit them for official
review. The reasons can be lack of hardware or time, loss of interest,
etc. But the packages exist and everybody is encouraged to grab them and
officially submit them on his own. It can even be used for packages that
are waiting for review or just undergoing the review, because the whole
process can last many months.

> 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

Sorry, I should have been more concrete - codeblocks has very few
releases, I dare to say one in many years, but I want to stick by the
releases for Fedora. The upstream releases so called "nightly snapshots"
time after time that can be interesting for some users and the
developers will appreciate any feedback on them.

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

Well, I can't image a situation where I would like to do both back- and
forward-port so lets merge them.

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

It is a view of my situation, a view how to utilize existing
infrastructure to bring more value for the users. And I expect that
there are other packagers in similar situation.


		Dan