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. > > > But the question is what should be the relation between new repo and > > RPMFusion > > BTW: It's "RPM Fusion" (with space) ;-) I wasn't sure and looks like I forgot to make at least the spell checker happy :-) > > and Fedora > > 1. can contain packages that are already in RPMFusion/Fedora? > > and when 1 = yes then > > Yes. Otherwise merging kde-redhat afaics wouldn't make much sense > > > 2. can include packages newer then rawhide? > > I'd say so. (As long term gnome user) I'm not familiar at all with > kde-redhat, but I think that's what they also do now and then (like > preparing kde 4.2 before it hit rawhide or 4.1 before it hit F9?) > > > 3. can contain backports of rawhide packages to stable releases? > > I'd say so. > > In general: I wouldn't want to many rules for those repos. But we need > to be very careful. Having to many of those repos could be dangerous > (for us), confusing (for the users) and time consuming (for infra and > the people that take care of the infra). And we of course need to make > sure that the main repo remains the repo that normally offers everything > ordinary users want. 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, ...) Dan