Re: Where we are and where do we what to go?
On 07.03.2009 21:39, Rahul Sundaram wrote: Thorsten Leemhuis wrote: I don't particularly care about officialness. It doesn't make any real difference to me but if you want to host a remix, Omega serves that purpose and more mirrors would be good for users using Omega. If we want to introduce process, we need people to participate. Who is stepping up to do the actual work of reviewing it? I'd do it for a official RPM Fusion spin if nobody else steps up. Endless discussions about this isn't leading to anything concrete here. In the absence of people helping out, what is the action plan? Then nothing happens. Not to mention legal aspects. The question - what to put on the servers aka *legal considerations*: What does it require from RPM Fusion? Do we need to host the SRPMs from Fedora to make sure we comply to the GPL even if the Fedora server drop of the net tomorrow? in http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-March/004090.html wasn't answered yet afaics Fedora servers (and mirrors) dropping off the net isn't a realistic scenario Sure it sounds unrealistic(¹); but that afaics doesn't matter at all afaics (see below). (¹) and I don't think it's that unrealistic; just for a moment think what could happen if evil company buys Red Hat tomorrow but mirroring SRPM's for the binary content in the live cd(s) would be a good idea nevertheless. The FSF GPL FAQ answers the specific legal requirements. Where exactly? Sorry if I sound dumb, but I just want to make sure we do everything right from the start to prevent running into situations where we'd violate the GPL. Note that http://fedoraproject.org/wiki/Legal/Distribution explicitly says: The Fedora Project hereby explicitly states that it follows option a) above, accompanying the binary code with a complete machine-readable copy of the corresponding source code. The Source RPMs are placed on the Fedora download servers alongside and concurrent with the Binary RPMs. Anyone obtaining any executable form of Fedora by downloading from one of Fedora's download servers may also voluntarily download the corresponding Source RPMs. The Fedora Project hereby explicitly states that it does _not_ follow option b) or c) above. [...] Hence we can't distribute our remixes under 3c afaics and point people to Fedora, as that would require Fedora to be distributed under 3b. But I'm not an expert in things like that. Maybe I got something wrong and that's why I think it's worth the time to discuss this here. See also: http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/4277 And also: http://lwn.net/Articles/193852/ MEPIS has typically used binary packages straight from the parent repository for large parts of the system. They never carried the source code for these unaltered packages. [...] Sending people to the parent source repository is not good enough, although they got away with it for some time. CU knurd
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: Sure it sounds unrealistic(¹); but that afaics doesn't matter at all afaics (see below). (¹) and I don't think it's that unrealistic; just for a moment think what could happen if evil company buys Red Hat tomorrow They don't control the dozens and dozens of volunteer mirrors. Where exactly? Sorry if I sound dumb, but I just want to make sure we do everything right from the start to prevent running into situations where we'd violate the GPL. I already said so. Mirror the SRPMs for content in the remixes. Rahul
Re: Where we are and where do we what to go?
On 03.03.2009 08:27, Rahul Sundaram wrote: Thorsten Leemhuis wrote: - ideally a KDE spin as well, as I would like to prevent RPM Fusion ignores KDE fame; related: the name discussion, as the basic name of our first spin should leave room for other spins, hence your spins would need to be something like Omega Desktop or Omega Gnome afaics It is already called as Omega Desktop. Sounds really good, as it leaves room for other omega variants :-) I don't have time to maintain another variant right now. I didn't mean you to do that. That why I wrote ideally ;-) We nevertheless IMHO once again should ask in public (blog and spins-list maybe?) if somebody want to do a KDE spin with RPM Fusion before we do one with Gnome -- then we can point users that complain why don't you hvae a KDE spin there and tell them nobody volunteered. - ideally at least two people that take care of the spins that review the work from each other a bit (IOW: we should at least basically review spins just like we review packages); Again and I can only ask for feedback. What do I do if I don't get any? Note that there is a ideally as well. But again: We don't allow packages that haven't been reviewed. Why should we allow spins that haven't been reviewed? - Fedora and RPM Fusion packages only Does that mean livna libdvdcss cannot be included or that livna repository cannot be enabled by default? I'd say so, because the reasons for not including libdvdcss in a spin are the same as for not including them in the repo. Cu knurd
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: We nevertheless IMHO once again should ask in public (blog and spins-list maybe?) if somebody want to do a KDE spin with RPM Fusion before we do one with Gnome -- then we can point users that complain why don't you hvae a KDE spin there and tell them nobody volunteered. Read my release notes. It already answers this question. But again: We don't allow packages that haven't been reviewed. Why should we allow spins that haven't been reviewed? There is no question of allowing anything. The remix already exists and people are using it. The only decision is to let the project use the rpmfusion volunteer mirrors or not. You still want to allow a staging repository for packages ( or Koji personal repos in Fedora land) because sometimes things have to happen first before others can participate. Again, anyone is welcome to participate. In the absence of participation, I still intend to continue to get things done. I'd say so, because the reasons for not including libdvdcss in a spin are the same as for not including them in the repo. I want the remix to be basically usable for me as it is and without libdvdcss, the benefit is much less and I bet everybody here is using it anyway but if there is interest in such a project, somebody else has to step up and do it. Omega can still use the Livna mirrors I guess. Rahul
Re: Where we are and where do we what to go?
On 07.03.2009 15:48, Rahul Sundaram wrote: Thorsten Leemhuis wrote: We nevertheless IMHO once again should ask in public (blog and spins-list maybe?) if somebody want to do a KDE spin with RPM Fusion before we do one with Gnome -- then we can point users that complain why don't you hvae a KDE spin there and tell them nobody volunteered. Read my release notes. It already answers this question. What do you mean? ftp://ftp.infradead.org/pub/spins/README.Omega-10-Release-Notes doesn#t contain the word KDE afaics. Or do you mean the Do you plan on do other variants? part? Whatever: If we want to do a spin as RPM Fusion project then I'd much prefer if we tell the world something like hey, a RPM Fusion Fedora reminx with Gnome is prepared and we'd like one with KDE as well, but don't have anyone working on yet, just to make sure nobody yells at us later. But again: We don't allow packages that haven't been reviewed. Why should we allow spins that haven't been reviewed? There is no question of allowing anything. I thought you wanted to make it a kind of official RPM Fusion remix? Isn't that the point of the whole discussion? I assume you do. Then we IMHO need to review it, similar to how spins are reviewed in Fedora afaics: https://fedoraproject.org/wiki/Spins_Process https://fedoraproject.org/wiki/Spins_SIG_Review_Checklist The remix already exists and people are using it. The only decision is to let the project use the rpmfusion volunteer mirrors or not. I for one think we should follow the fedora rules when it comes to spins (or remixes in this case) just like we follow the Fedora rules elsewhere as well. The reasons for that IMHO are similar as in Fedora: it's the projects reputation that rises or falls with the quality of spins we host. Not to mention legal aspects. The question - what to put on the servers aka *legal considerations*: What does it require from RPM Fusion? Do we need to host the SRPMs from Fedora to make sure we comply to the GPL even if the Fedora server drop of the net tomorrow? in http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-March/004090.html wasn't answered yet afaics. [...] Again, anyone is welcome to participate. In the absence of participation, I still intend to continue to get things done. You are free to do so and I really appreciate your efforts. [...] CU knurd
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: What do you mean? ftp://ftp.infradead.org/pub/spins/README.Omega-10-Release-Notes doesn#t contain the word KDE afaics. Or do you mean the Do you plan on do other variants? part? Latter. It clearly informs everyone that they are free to do additional variants and are welcome to do so. I thought you wanted to make it a kind of official RPM Fusion remix? Isn't that the point of the whole discussion? I assume you do. Then we IMHO need to review it, similar to how spins are reviewed in Fedora afaics: I don't particularly care about officialness. It doesn't make any real difference to me but if you want to host a remix, Omega serves that purpose and more mirrors would be good for users using Omega. If we want to introduce process, we need people to participate. Who is stepping up to do the actual work of reviewing it? Endless discussions about this isn't leading to anything concrete here. In the absence of people helping out, what is the action plan? Not to mention legal aspects. The question - what to put on the servers aka *legal considerations*: What does it require from RPM Fusion? Do we need to host the SRPMs from Fedora to make sure we comply to the GPL even if the Fedora server drop of the net tomorrow? in http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-March/004090.html wasn't answered yet afaics Fedora servers (and mirrors) dropping off the net isn't a realistic scenario but mirroring SRPM's for the binary content in the live cd(s) would be a good idea nevertheless. The FSF GPL FAQ answers the specific legal requirements. Rahul
Re: Where we are and where do we what to go?
Rahul Sundaram wrote: Thorsten Leemhuis wrote: - ideally a KDE spin as well, as I would like to prevent RPM Fusion ignores KDE fame; related: the name discussion, as the basic name of our first spin should leave room for other spins, hence your spins would need to be something like Omega Desktop or Omega Gnome afaics It is already called as Omega Desktop. It's a meritocracy afterall, Rahul did the work here, he should get the major say in naming. And to confirm, he did approach the kde-sig about are kde variant... and I offered to help when I had time (famous last words). -- Rex
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: - Fedora and RPM Fusion packages only Not including libdvdcss kinda defeats the point of Omega. Kevin Kofler
Re: Where we are and where do we what to go?
Kevin Kofler wrote: Thorsten Leemhuis wrote: - Fedora and RPM Fusion packages only Not including libdvdcss kinda defeats the point of Omega. Shrug, it's one less thing there's still all the driver and codec support. -- Rex
Re: Where we are and where do we what to go?
On 01.03.2009 00:05, Rahul Sundaram wrote: Thorsten Leemhuis wrote: [Catching up on this after a long time so excuse the delay] - no RPM Fusion Fedora remix maintained within the project; do we want one? Or even proper install DVDs that already contain packages from RPM Fusion? I was very happy to see Rahul do some work here, way to go Rahul! I don't care much if the remix is an official part of rpmfusion or not. In my experience having such things outside the project IMHO leads to confusion among the users; sooner or later others might start creating their own RPM Fusion spins, which often lead to competition instead of cooperation :-/ I have asked multiple times with no clear decision. Well, from my point of view the whole process had a very bad start. Two reasons (among others) for that *option* of mine: (a) you tried to do many things own your own (e.g. presenting something nearly finished including a name for it) without getting the list properly involved *early* enough in the process; yes, I know, you tried to get it involved, but maybe not hard enough and/or to late; maybe it was simply bad luck (people on vacation maybe?); (b) is also part of the problem (b) seems many people are interested in a spin, but either found no time to participate or are not much more then interested (e.g. not willing to invest time for it, but would like it; that's a general problem in RPM Fusion afaics) Maybe putting everything aside and starting fresh might help; e.g. discuss what we want: name(s), target audience, gnome vs. kde (we should do both), free and nonfree, Live-Spin vs. regular install media, ...; that might help to get things rolling again (but maybe I'm wrong with that). Sure that is slower, but it might lead to what we all want ;-) There is theory a steering committee who is in charge but it doesn't seem active. I brought that topic up a few days already in a mail. Until that is solved: If you want to get something decided by the steering committee then ask it and I'm sure you'll get an answer. But right now there isn't much to decide afaik, as omega includes packages that are not part of Fedora and RPM Fusion. That IMHO makes it just as unacceptable for RPM Fusion as an official Fedora spin with a RPM Fusion package in it. If RPM Fusion as a project want to host the kickstart file, images and help review, test and provide feedback on anything related to the live cd, I would be happy to participate. Sounds good. As long as decisions don't get done, I would have to continue hosting it outside this project. That's for me sounds a lot like my packages were not reviewed; there wasn't even a real reviewer, just a few random comment; so instead of trying harder or getting exchange reviews organized I start my own repo instead of participating to Fedora or RPM Fusion. I continue to point users to this mailing list for discussions and continue to post updates here whenever anything related to the live cd happens. A note on the live cd, I am including libdvdcss so you might want to consider the effect of that on hosting. Regarding that: For my option on that see above. CU knurd
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: (a) you tried to do many things own your own Isn't that what you are doing too? E.g. when you single-handedly decided to ban libdvdcss and flame everybody who objecs to it? Which incidentally is also causing this issue: But right now there isn't much to decide afaik, as omega includes packages that are not part of Fedora and RPM Fusion. That said: gnome vs. kde (we should do both) +1 The current Omega isn't of much use to KDE users. free and nonfree If we want to ship a nonfree CD at all, there should also be a free one indeed. Kevin Kofler
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: Maybe putting everything aside and starting fresh might help; e.g. discuss what we want: name(s), target audience, gnome vs. kde (we should do both), free and nonfree, Live-Spin vs. regular install media, ...; that might help to get things rolling again (but maybe I'm wrong with that). Sure that is slower, but it might lead to what we all want ;-) You keep repeating the same thing over and over again and I am getting really tired of explaining this to you. Just drop it and move on. If you want to insist on a new name, go ahead and be my guest. If you find consensus, let me know. I am building on a desktop kickstart based live cd and that's all I have time for. If others want to build a KDE based live cd, sure, feel free to participate. I did inform Rex Dieter and others in the KDE SIG this. I brought that topic up a few days already in a mail. Until that is solved: If you want to get something decided by the steering committee then ask it and I'm sure you'll get an answer. But right now there isn't much to decide afaik, as omega includes packages that are not part of Fedora and RPM Fusion. That IMHO makes it just as unacceptable for RPM Fusion as an official Fedora spin with a RPM Fusion package in it. You already brought this up before and I repeat, there is nothing outside of Fedora and RPM Fusion packages in Omega. As long as decisions don't get done, I would have to continue hosting it outside this project. That's for me sounds a lot like my packages were not reviewed; there wasn't even a real reviewer, just a few random comment; so instead of trying harder or getting exchange reviews organized I start my own repo instead of participating to Fedora or RPM Fusion. Nothing close to it. I wanted to host Omega in RPM Fusion mirrors. I asked on list a few times and no decision was ever made. The option was to drop all my work on the floor or host it elsewhere. I am hosting it elsewhere till people here decide on something since I did not want my work to be wasted. I will ask again, are you or the steering committee or whoever it is that is making the decision now willing to host Omega? Rahul
Re: Where we are and where do we what to go?
Kevin Kofler wrote: gnome vs. kde (we should do both) +1 The current Omega isn't of much use to KDE users. Then build a KDE variant. What is stopping you? Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: But right now there isn't much to decide afaik, as omega includes packages that are not part of Fedora and RPM Fusion. That IMHO makes it just as unacceptable for RPM Fusion as an official Fedora spin with a RPM Fusion package in it. I will just add this: In my previous reply I said that only Fedora and RPM Fusion packages are included. There is however a single exception to this. libdvdcss from Livna is also included as I already noted before but I wanted to clarify that now as well just in case you missed that. Everything is covered in detail at ftp://ftp.infradead.org/pub/spins/README.Omega-10-Release-Notes Rahul
Re: Where we are and where do we what to go?
On Monday 02 March 2009 03:56:45 pm Rahul Sundaram wrote: Kevin Kofler wrote: gnome vs. kde (we should do both) +1 The current Omega isn't of much use to KDE users. Then build a KDE variant. What is stopping you? Rahul Lack of interest. -- Conrad Meyer kon...@tylerc.org
Re: Where we are and where do we what to go?
On 02.03.2009 20:57, Kevin Kofler wrote: Thorsten Leemhuis wrote: (a) you tried to do many things own your own Isn't that what you are doing too? I'm well aware that I sometimes might have done that now and then -- especially in the phase to get RPM Fusion started, as I got the impression everyone waited for someone to drive things forward, so I did when everything seemed stuck. But I always try to announce things *early* in the process to give people a chance to influence stuff before I do it. But if I got to far somewhere: Sorry. E.g. when you single-handedly decided to ban libdvdcss Check the archives. It wasn't my decision alone; it was one of the decisions from the steering committee. In fact it were others that were against it in the beginning when I was still undecided. Reverting that decision now is hard. There are contributors that invested a lot of time in RPM Fusion just on the fact that we don't ship libdvdcss -- stating to ship it now might kick those people out, which imho would be a bit unfair. [...] CU knurd
Re: Where we are and where do we what to go?
On 03.03.2009 06:44, Thorsten Leemhuis wrote: On 02.03.2009 20:57, Kevin Kofler wrote: Thorsten Leemhuis wrote: (a) you tried to do many things own your own Isn't that what you are doing too? I'm well aware that I sometimes might have done that now and then -- especially in the phase to get RPM Fusion started, as I got the impression everyone waited for someone to drive things forward, so I did when everything seemed stuck. But I always try to announce things *early* in the process to give people a chance to influence stuff before I do it. But if I got to far somewhere: Sorry. BTW, I in the initial mail of this thread already raised the need to maybe form a real steering committee and have regular IRC meeting. Kevin, as you seem to be unhappy: Do you maybe want to drive that forward? Cu knurd
Re: Where we are and where do we what to go?
On 03.03.2009 00:55, Rahul Sundaram wrote: Thorsten Leemhuis wrote: [...] I will ask again, are you or the steering committee or whoever it is that is making the decision now willing to host Omega? I for one would like to see this (from the top of my head; maybe I forget something) before I'd be willing to say yes: - rediscusison of the name -- I'd much prefer something with RPM Fusion in the name; other iirc indicated a similar opinion; but I have no problem with Omega if that the consensus; maybe something like Omega -- RPM Fusion's Fedora remix makes everybody happy? In short it would be Omega then everywhere :-) - ideally a KDE spin as well, as I would like to prevent RPM Fusion ignores KDE fame; related: the name discussion, as the basic name of our first spin should leave room for other spins, hence your spins would need to be something like Omega Desktop or Omega Gnome afaics - ideally at least two people that take care of the spins that review the work from each other a bit (IOW: we should at least basically review spins just like we review packages); - Fedora and RPM Fusion packages only - where to put the stuff on the server - what to put on the servers aka *legal considerations*: What does it require from RPM Fusion? Do we need to host the SRPMs from Fedora to make sure we comply to the GPL even if the Fedora server drop of the net tomorrow? - at least basically discuss where and how are those spins are created -- security and trust are crucial here; and yes, I fully trust you, but what do we do if some random Fedora fan nobody knows comes tomorrow and wants to get his remix hosted on our server? CU knurd
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: - ideally a KDE spin as well, as I would like to prevent RPM Fusion ignores KDE fame; related: the name discussion, as the basic name of our first spin should leave room for other spins, hence your spins would need to be something like Omega Desktop or Omega Gnome afaics It is already called as Omega Desktop. I don't have time to maintain another variant right now. Somebody interested should step up to do that if they want more. - ideally at least two people that take care of the spins that review the work from each other a bit (IOW: we should at least basically review spins just like we review packages); Again and I can only ask for feedback. What do I do if I don't get any? - Fedora and RPM Fusion packages only Does that mean livna libdvdcss cannot be included or that livna repository cannot be enabled by default? Then I don't really see the point. Rahul
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: [Catching up on this after a long time so excuse the delay] - no RPM Fusion Fedora remix maintained within the project; do we want one? Or even proper install DVDs that already contain packages from RPM Fusion? I was very happy to see Rahul do some work here, way to go Rahul! I don't care much if the remix is an official part of rpmfusion or not. In my experience having such things outside the project IMHO leads to confusion among the users; sooner or later others might start creating their own RPM Fusion spins, which often lead to competition instead of cooperation :-/ I have asked multiple times with no clear decision. There is theory a steering committee who is in charge but it doesn't seem active. If RPM Fusion as a project want to host the kickstart file, images and help review, test and provide feedback on anything related to the live cd, I would be happy to participate. As long as decisions don't get done, I would have to continue hosting it outside this project. I continue to point users to this mailing list for discussions and continue to post updates here whenever anything related to the live cd happens. A note on the live cd, I am including libdvdcss so you might want to consider the effect of that on hosting. Rahul
Re: Where we are and where do we what to go?
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
Re: Where we are and where do we what to go?
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... CU knurd
Re: Where we are and where do we what to go?
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
Re: Where we are and where do we what to go?
On Sun, Feb 08, 2009 at 10:06:29AM +0100, Thorsten Leemhuis wrote: 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 think it would be great. Adrian
Re: Where we are and where do we what to go?
Andrea Musuruane wrote: I have placed known testing/staging repositories in a different section in : http://rpmfusion.org/FedoraThirdPartyRepos I have tracked most 3rd party maintainers/packagers too. We should have an agreed invite mail mail here: http://rpmfusion.org/InviteThirdPartyRepo So, what next? Who's gonna send this email to 3rd party maintainers/packagers? Excellent work. I'd suggest a rpmfusion representative volunteer for each repo, particularly someone who has some familiarity with the repo or who runs it. In the meantime, I'll go adjust the wiki to move kde-redhat to the compatible section. :) -- Rex
Re: Where we are and where do we what to go?
Andrea Musuruane wrote: On Mon, Jan 26, 2009 at 10:52 PM, Hans de Goede j.w.r.dego...@hhs.nl wrote: If all of us contribute a little to track down the maintainers, we could at least try to contact them, ask them to join, listen to their complains, guide them in the project. Strong +1 Here it is a little draft of the mail we could send to 3rd party repo maintainers: http://rpmfusion.org/InviteThirdPartyRepo Please review it, add missing bits, tell what you think :) Bye, Andrea. Looks good to me. Regards, Hans
Re: Where we are and where do we what to go?
On Tue, Jan 27, 2009 at 7:00 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: Many thx for that. Three small details: You are welcome. - users in the past could easily see which repos were compatible with RPM fusion and which not; now that easily lost in the noise; I'm wondering if it would have been better to split the information that are relevant for us and those that are relevant for users into separate pages You have a point here. But for now, I'd prefer to have to edit a single page instead of two. Later, when we'll contact maintainers, we can do the split. Does this sound fine? - how about fields like Last Contacted and/or interested in merging with RPM Fusion. We can do it when we'll split the page. - some of the repos seem to be outdated (Dr Pixel; Fedora-xgl); should we remove them? I think we should keep them, but in a different section. Usually maintainers (or maybe it is just me?) look for already (but eventually not up to date) Fedora packages. Bye, Andrea.
Re: Where we are and where do we what to go - encouraging third party repos.
Andrea Musuruane wrote: invite 3rd party maintainers again and ask them to join. If they don't want to join, we should politely ask why. We should stress about our strengths and the benefits of joining (only one repo, very visible, peer review to improve quality, build system, cvs, etc). - Are we better at backups ? How are we protected from various potential hardware failures / issues ? - Can we present estimates on user base ? for each repo ? [and if this is bigger than I imagined - would making such info available potentially bring the big fish circling - trying to get packages removed and so forth ?]. - Having lots of regularly updated mirrors is a positive to mention; leads to faster user installs and updates, and (if mirrormanager is giving out a prioritized list) better resiliency. They would be welcome to become an extra mirror, so that their exsting resources (web host, bandwidth) can still be used if they wish. - Having external packagers being able to easily manage the actual package push requst (bohdi), and to easily link amongst cvs, koji, bohdi and package db - just like fedora - would probably help them to feel that they are still reasonably in control. Although, this gets back to limited persons with the sign/push capability. DaveT.
Re: Where we are and where do we what to go?
On Mon, Jan 26, 2009 at 10:52 PM, Hans de Goede j.w.r.dego...@hhs.nl wrote: We already have a page in the wiki to track third party repositories. http://rpmfusion.org/FedoraThirdPartyRepos If all of us contribute a little to track down the maintainers, we could at least try to contact them, ask them to join, listen to their complains, guide them in the project. Strong +1 I have updated the wiki page adding many contact info. Plase add others if you /know them. Bye, Andrea.
Re: Where we are and where do we what to go?
On 27.01.2009 18:48, Andrea Musuruane wrote: On Mon, Jan 26, 2009 at 10:52 PM, Hans de Goede j.w.r.dego...@hhs.nl wrote: We already have a page in the wiki to track third party repositories. http://rpmfusion.org/FedoraThirdPartyRepos If all of us contribute a little to track down the maintainers, we could at least try to contact them, ask them to join, listen to their complains, guide them in the project. Strong +1 I have updated the wiki page adding many contact info. Many thx for that. Three small details: - users in the past could easily see which repos were compatible with RPM fusion and which not; now that easily lost in the noise; I'm wondering if it would have been better to split the information that are relevant for us and those that are relevant for users into separate pages - how about fields like Last Contacted and/or interested in merging with RPM Fusion. - some of the repos seem to be outdated (Dr Pixel; Fedora-xgl); should we remove them? CU knurd
Re: Where we are and where do we what to go?
Stewart Adam wrote: On 1/25/09 1:33 PM, Thorsten Leemhuis wrote: Hi! snip - some of our processes are afaics not documented at all or not properly documented I've been wanting to bring this up - I think our /Contributors page needs some parts rewritten, and a bit more added in certain spots. We should also create a page with guidelines specific to RPM Fusion (kmods should be mentioned and licensing also comes to mind so we don't have libdvdcss all over again). Also, I don't have a tremendous amount of experience using CVS so I may be completely wrong, but getting the CVSROOT right is annoying; I've put the following in ~/.bashrc to help: * alias plague-client-rf='PLAGUE_CLIENT_CONFIG=~/.plague-client-rpmfusion.cfg plague-client' * alias cvsf='export CVSROOT=:ext:usern...@cvs.fedora.redhat.com:/cvs/extras' * alias cvsrf='export CVSROOT=:ext:usern...@cvs.rpmfusion.org:/cvs/free' * alias cvsrnf='export CVSROOT=:ext:usern...@cvs.rpmfusion.org:/cvs/nonfree' Maybe we should include this too in /Contributors? Sounds like a good idea (I use something similar). snip - still lots of other 3rd party repos out there; users still run into problems as they try to mix incompatible repos; should we actively try to get more repos merged into RPM Fusion? I think so... One of my own thoughts about what we should be is a place for users to receive high quality packages that compliment the Fedora ones. IMHO, we should aim to be *the* place for users to get everything they need that's not included in Fedora. snip +1 Regards, Hans
Re: Where we are and where do we what to go?
On 26.01.2009 01:05, David Timms wrote: Hans de Goede wrote: Thorsten Leemhuis wrote: ... - we started a few months ago and it worked out quite well afaics; right now the repos and the packages in it might not be perfect, but the repos overall were and still are in acceptable good condition Yes I'm quite happy with things how they are :) I agree with that. Do our users agree ? - can we count how many users we have ? No, I only have access to the awstats from download1.r.c - can we count how many updaters we have ? updaters? We might be able to check how many people hit mirros.rpmfusion.org, but - those are two or three machines as well - not everyone uses mirrormanager - could we get such info from the mirrors ? Don't think so. - before the above, do people consider getting such info out of web logs to be an invasion of privacy ? Checking the number of visitors shouldn't be a big problem. But in general: putting a privacy policy somewhere in our wiki (simply copy the one from Fedora?) might be a good idea. - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher Your to critical I'm quite happy with the steady trickle of new contributers, welcome all! And for most serious packages, it is not a breeze to bang up a .spec and get it reviewed (mine took around a year from my first work on a spec until finally ready for inclusion). Related: What I'd really like to prevent is that our list of unassigned review-bugs gets to long... But I far prefer this than having a zillion app users configure, make, make install packages they find on the net. We do need to ensure that all reviewers do so in a positive frame of mind, rather than being abusive or dictatorial in their responses. We don't want the packager to be put off, neither do we want other readers of the review (eg from a mailing list archive when a user does a search for something) to think that being part of the RPM Fusion sounds bad / is a stress etc. +1 [...] Other things I don't know about EL: - do the public have access to a continual stream of rawhide packages like fedora ? No, there isn't something like a EL-rawhide - do the public have access to beta releases ? In the past that was the case. should do it for EL; BTW, where did all those go that were interested in supporting EL as they maintained their own rpmfusion/livna rebuilds for EL somewhere already)? Perhaps it is too easy to createrepo and publish somewhere on the web. Yes, definitely ;-) [...] trustworthy; being on IRC a lot would make coordination easier) -- Trustworthy is the key of course. We (both users and packagers) need to be confident that: - the key won't go missing - the key won't be used except as needed by rpm fusion signing process Agree to these. - the person(s) has actually checked the diffs of packages to ensure no skulduggery [1] is occurring. No, but that's not the case -- the signers in Fedora or RPM Fusion trust that the tarballs and patches that get uploaded by the packagers are good. [...] - some ideas for new repos were mentioned (staging; unstable; someone iirc also mentioned the idea to get kde-redhat under the hood, which could have benefits for both sides), but nobody drove those ideas forward I think that would spread us too thin, focus is important, I think it is important we define out goals clear, see below. Agreed. In terms of the earlier mentioned issue of push time, would it make sense (or even save time?) to have an 'updates-bulk' (think of a better name) repo. This could once a month or so, take all 'updates' as we currently know them and split the repo into all changes from release to this point in time. Any new updates during the intervening month could be in an 'updates-recent' repo, so that user machines only have to download repo metadata of a size related to the changes within a smaller timeframe. We already have updates-testing, where new and updated packages normally stay for 7 to 14 days. That should be enough afaics. - still lots of other 3rd party repos out there; users still run into problems as they try to mix incompatible repos; should we actively try to get more repos merged into RPM Fusion? Yes! I haven't been on lists etc where users are having such trouble recently (actually one I did suggest going with RPM Fusion rather than a troublesome combination of 4 other external repos. There was someone on fedora-list recently that had trouble, as he had atrpms and rpmfusion enabled. - out graphics driver packages seem to have not a real good reputation: users accidentally remove the stuff that is needed in xorg.conf with tools like ati-config, nvidia-xconfig, ... and hence break the drivers. Users are also confused by the different drivers; many don't know which one to choose (legacy, 96xx, 173xx, beta, ...) I recently
Re: Where we are and where do we what to go?
Michael Schwendt wrote: On Mon, 26 Jan 2009 12:53:46 +0100, Thorsten wrote: - still lots of other 3rd party repos out there; users still run into problems as they try to mix incompatible repos; should we actively try to get more repos merged into RPM Fusion? Yes! I haven't been on lists etc where users are having such trouble recently (actually one I did suggest going with RPM Fusion rather than a troublesome combination of 4 other external repos. There was someone on fedora-list recently that had trouble, as he had atrpms and rpmfusion enabled. ffmpeg vs. ffmpeg-libs as well as x264 currently cause unresolved deps due to soname differences. Do you think RPM Fusion packages should include conflicts or similar (with external 3rd party repos packaging) to stop an install that would cause the two styles of packaging to both be installed ? DaveT.
Re: Where we are and where do we what to go?
thx for your comments (same to Hans and David btw) On 25.01.2009 23:10, Stewart Adam wrote: On 1/25/09 1:33 PM, Thorsten Leemhuis wrote: [...] - we started a few months ago and it worked out quite well afaics; right now the repos and the packages in it might not be perfect, but the repos overall were and still are in acceptable good condition - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher - activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started :-( we just do business as usual, which might be very dangerous in the long term - no automatic dep check script running that makes sure our repo is in a sane state; that is something we really need! I'm interested in doing this, but I'm not sure when I'll actually be able to get around what the requirements wrt the build system are. IIRC somebody linked to a python script that did this on fedora-devel-list not so while back, maybe we can use that. The script from mschwendt might be the best; it (or a older version) reused parts from the push script (maybe only in older versions), which might make things easier. I'll talk to him in case Xavier doesn't want to handle it or worked on it. [...] - a good bunch of mirrors and a nice infra to manage them; what are those metalink urls that fedora recently started to use for the alpha? should we use those in the future as well? According to http://metalinker.org, it combines FTP, HTTP and P2P capabilities together for extremely fast download speeds, along with error checking and redundancy (if mirrors are bad, it can skip them + move on). I guess that's something else ;-) http://fedoraproject.org/wiki/Features/YumMetalinks [...] - some of our processes are afaics not documented at all or not properly documented I've been wanting to bring this up - I think our /Contributors page needs some parts rewritten, and a bit more added in certain spots. We should also create a page with guidelines specific to RPM Fusion (kmods should be mentioned and licensing also comes to mind so we don't have libdvdcss all over again). +1 Also, I don't have a tremendous amount of experience using CVS so I may be completely wrong, but getting the CVSROOT right is annoying; I've put the following in ~/.bashrc to help: * alias plague-client-rf='PLAGUE_CLIENT_CONFIG=~/.plague-client-rpmfusion.cfg plague-client' * alias cvsf='export CVSROOT=:ext:usern...@cvs.fedora.redhat.com:/cvs/extras' * alias cvsrf='export CVSROOT=:ext:usern...@cvs.rpmfusion.org:/cvs/free' * alias cvsrnf='export CVSROOT=:ext:usern...@cvs.rpmfusion.org:/cvs/nonfree' Maybe we should include this too in /Contributors? I'd make a few functions that switch all the important bits between Fedora and RPM Fusion free/nonfree with one command. - documentation in general: there are lots of FAQ, Howto and other docs on the net that describe how to use RPM Fusion; often those are misleading, not fully right, outdated or they disagree with each other; should we try to not only be the inoffical official 3rd party repo for Fedora, but also be the offical 3rd party source for all the docs that can't go straight to Fedora? If we want to go ahead with this, I've already setup the Wiki pages for that [1]. Package maintainers (or someone else, if the maintainer is OK with it) would just have to write a quick blub on their Package/PackageName page documenting any known problems, workarounds, etc - anything 3rd party howtos or documentation would normally mention. Well, we really need to be behind the idea -- it might not help that much if some packages are documented really good, while others are not documented at all. - still lots of other 3rd party repos out there; users still run into problems as they try to mix incompatible repos; should we actively try to get more repos merged into RPM Fusion? I think so... But how to we get people to merge their repos into RPM Fusion? Especially the popular ones like Planet CCRMA? One of my own thoughts about what we should be is a place for users to receive high quality packages that compliment the Fedora ones. IMHO, we should aim to be *the* place for users to get everything they need that's not included in Fedora. +1 -- and to be *the* place we also need to have at least a unstable or playground repo, where those things can get done that we normally don't want to do. Without such a repo we force people to start their own. Reviews also need to be easy and quick. - rpmfusion-buildsys broken; no announcement mailing list; no real planet or other things to get important information out to the users The managers at FedoraForum.org are pretty good at watching what's going on, Well, that's just one forum (albeit and important one) -- there are hundreds of forums and lists on the net and there
Re: Where we are and where do we what to go?
Andrea Musuruane wrote: IMHO this is not the main problem with other repositories not joining RPM Fusion. Some packagers don't want to learn/use Fedora guidelines. Some others use Fedora guidelines but do not want to cooperate with a (much bigger) project because they just want to mind their own business. Some others are willing to cooperate but they think that the infrastructure we and Fedora have is too complicated. And some others know the guidelines very well, know just as well that their packages need fixing to be compliant, but still want them to be available somewhere until they get around to fixing them. (That's the case of the stuff on CalcForge and a few other small repos (I think kwizart's repo is similar, for example).) Kevin Kofler
Re: Where we are and where do we what to go?
On Mon, 26 Jan 2009 15:59:43 +0100, Thorsten wrote:
On 26.01.2009 13:29, David Timms wrote:
Michael Schwendt wrote:
On Mon, 26 Jan 2009 12:53:46 +0100, Thorsten wrote:
- still lots of other 3rd party repos out there; users still run
into problems as they try to mix incompatible repos; should we
actively try to get more repos merged into RPM Fusion?
Yes!
I haven't been on lists etc where users are having such trouble recently
(actually one I did suggest going with RPM Fusion rather than a
troublesome combination of 4 other external repos.
There was someone on fedora-list recently that had trouble, as he had
atrpms and rpmfusion enabled.
ffmpeg vs. ffmpeg-libs as well as x264 currently cause unresolved deps
due to soname differences.
Do you think RPM Fusion packages should include conflicts or similar
(with external 3rd party repos packaging) to stop an install that would
cause the two styles of packaging to both be installed ?
I have thought about that as well since the recent discussion on
fedora-list (the one where mschwendt provided more details).
I tend to think it would be good to do. But OTOH: I fear that people
don't properly why it's done and we might be the bad guys from their
point of view.
Bad idea, IMO.
It's only possible to conflict with NEVR tuples, but not with repo ids.
If packages from different repos share some package names, you've lost.
Explicit Conflicts also cannot protect against unresolvable
dependencies.
The conflicts in ffmpeg/x264 apparently are older, btw, and reappear
during dependency resolving:
| http://dl.atrpms.net/all/ffmpeg.spec
|
| Obsoletes: ffmpeg-libs = %{evr}
| %lib_dependencies
|
| * Sun Nov 16 2008 Axel Thimm Axel Thimm ATrpms net - 0.4.9-28_r15845
| - ffmpeg-libs from a 3rd party repo generates conflicts.
Re: Where we are and where do we what to go?
On 26.01.2009 19:04, Michael Schwendt wrote: On Mon, 26 Jan 2009 15:59:43 +0100, Thorsten wrote: On 26.01.2009 13:29, David Timms wrote: Michael Schwendt wrote: On Mon, 26 Jan 2009 12:53:46 +0100, Thorsten wrote: - still lots of other 3rd party repos out there; users still run into problems as they try to mix incompatible repos; should we actively try to get more repos merged into RPM Fusion? Yes! I haven't been on lists etc where users are having such trouble recently (actually one I did suggest going with RPM Fusion rather than a troublesome combination of 4 other external repos. There was someone on fedora-list recently that had trouble, as he had atrpms and rpmfusion enabled. ffmpeg vs. ffmpeg-libs as well as x264 currently cause unresolved deps due to soname differences. Do you think RPM Fusion packages should include conflicts or similar (with external 3rd party repos packaging) to stop an install that would cause the two styles of packaging to both be installed ? I have thought about that as well since the recent discussion on fedora-list (the one where mschwendt provided more details). I tend to think it would be good to do. But OTOH: I fear that people don't properly why it's done and we might be the bad guys from their point of view. Bad idea, IMO. As I said, I was unsure about the general idea myself right from the start, hence I didn't even think about details how to do it. It's only possible to conflict with NEVR tuples, but not with repo ids. Well, I had more meant to conflict with packages like atrpms-release in general. But I guess that confuses and hurts more than it helps, that's why I abandoned the idea earlier. I wouldn't have mentioned it on the list normally. [lot's of other good reasons why conflicting is a bad idea stripped] CU knurd
Re: Where we are and where do we what to go?
On 26.01.2009 17:49, Andrea Musuruane wrote: But how to we get people to merge their repos into RPM Fusion? Especially the popular ones like Planet CCRMA? IIRC Planet CCRMA is/was merging with Fedora. http://fedoraproject.org/wiki/AudioCreation I know, but I thought there were some packages in Planet CCRMA that might not be acceptable for Fedora. [...] IMHO this is not the main problem with other repositories not joining RPM Fusion. Some packagers don't want to learn/use Fedora guidelines. Some others use Fedora guidelines but do not want to cooperate with a (much bigger) project because they just want to mind their own business. Some others are willing to cooperate but they think that the infrastructure we and Fedora have is too complicated. In all these cases, they end up building their own repository. Well, you point out some of the reasons why I brought the idea with the staging repo up a few weeks ago: Have a repo where the review hurdle is a lot lower. So, how can we attract other 3rd party repositories? Make things as easy as possible for them. Lowering the review burden likely is the most important point here. [...] BTW, which repositories have been invited in the past? I remember to have contacted Bruno Postle and he joined. I once asked gemi, but he iirc would prefer to see others taking his packages and bringing them to Fedora or RPM Fusion (that's the long story very short and roughly without the details). Like the one I started a few months ago? It wasn't used much yet http://rpmfusion.org/News We should ask Chris Nolan about this. The solution was ready. I think the only problem he still had was about the domain/certificate to use. Yeah, Ohoh: I doubt that the planet will work, as the wiki page (which is easier to deal with) failed already. [...] CU knurd
Re: Where we are and where do we what to go?
On Mon, Jan 26, 2009 at 6:18 PM, Kevin Kofler kevin.kof...@chello.at wrote: And some others know the guidelines very well, know just as well that their packages need fixing to be compliant, but still want them to be available somewhere until they get around to fixing them. (That's the case of the stuff on CalcForge and a few other small repos (I think kwizart's repo is similar, for example).) Kevin, I didn't say that there isn't a need for such repo, I just said that IMHO it is not our main problem in attracting 3rd party repositories. After all, you and kwizart already take part (an important part!) in RPM Fusion. If I may add, I do not oppose the creation of such repository. The only doubt about it is, because the packages in there wouldn't polished (i.e. not peer reviewed, not in good shape, etc), what will happen when users will have problems. Will they blame the quality of RPM Fusion? Bye, Andrea.
Re: Where we are and where do we what to go?
Andrea Musuruane wrote: On Mon, Jan 26, 2009 at 8:22 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: IIRC Planet CCRMA is/was merging with Fedora. http://fedoraproject.org/wiki/AudioCreation I know, but I thought there were some packages in Planet CCRMA that might not be acceptable for Fedora. I think Hans could answer this. IIRC he took part in the talks to merge Planet CCRMA in Fedora. Yes, the biggest problem here is time, we simply need someone to get each and every package in ccrma, clean it up and submit it for review. I'm hereby doing the crazy thing of volunteering to do the needed reviews, but I do not have the time to push this forward my self atm. As far as rpmfusion is involved here, there might be a few things which need to go to rpmfusion, but that in no way is the biggest problem. I once asked gemi, but he iirc would prefer to see others taking his packages and bringing them to Fedora or RPM Fusion (that's the long story very short and roughly without the details). We already have a page in the wiki to track third party repositories. http://rpmfusion.org/FedoraThirdPartyRepos If all of us contribute a little to track down the maintainers, we could at least try to contact them, ask them to join, listen to their complains, guide them in the project. Strong +1 Regards, Hans
Re: Where we are and where do we what to go?
One addition: On 26.01.2009 16:25, Thorsten Leemhuis wrote: [...] = Where we want to go = The where we are part already had some areas and suggestion where things need to be improved; here are some more: - it would be really nice to have a small helper app that is used for enabling RPM Fusion and initial configuration. E.g. users could download that helper app rpm instead of the two release-rpms (or it could be part of the rpmfusion-free-release rpm); that helper app then could ask a few questions like Do you want nonfree packages? or do you want to enable compatible repos like the adobe repo?. After that it could act according to what the user wants and what's found on the system (e.g. install rpmfusion-nonfree-release; install xine-lib-extras-nonfree if xine-lib is found; same for gstreamer-plugins, k3b and others; this maybe should be done by a daemon later as well to keep things smooth); maybe this helper app could even enable livna, but that might be tricky as the livna repofile must not be in that package (I guess retrieving the data from the net OHOH should be save) . Yes, I'm fully aware that such apps that do parts of this exist already. But some do stupid things and everyone could benefit from a sane app official app in RPM Fusion. I've spoken to the author of Autonine/Autoten http://www.dnmouse.org/autoten.html about this, I haven't taken a look at the script recently but iirc we could easily make those improvements, get it peer-reviewed and make it the official RPM Fusion enabler script. Before that it needs to become a whole lot easier to use and ask only important questions by default (mainly: Do you want nonfree or not?) Ohh, and it would be nice if the tool could have a command line interface as well, so people can use it in the %post section of their kickstart file for normal installs or spin creation. Yes, it's a detail, but an important one I'd say. CU knurd
Where we are and where do we what to go?
Hi! It afaics can help a lot to now and then step back for a moment and try to look with at where we are some distance; after that it's often the time to think about where we want to be in one, two or five years from now. I tried to do that over the last few days; find my thoughts below. One note: consider to stop reading this mail *now* temporary and instead quickly and roughly write down a few of your own thoughts of where RPM Fusion is and where it should head to. After that continue to read this mail -- if you find that some of your thoughts are missing in below list consider to send them to the mailing list for wider discussion. = Where we are = - we started a few months ago and it worked out quite well afaics; right now the repos and the packages in it might not be perfect, but the repos overall were and still are in acceptable good condition - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher - activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started :-( we just do business as usual, which might be very dangerous in the long term - no automatic dep check script running that makes sure our repo is in a sane state; that is something we really need! - EL repo: We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of release manager (I'm doing that job a bit for the Fedora repos; someone else, that actually uses EL more than I do should do it for EL; BTW, where did all those go that were interested in supporting EL as they maintained their own rpmfusion/livna rebuilds for EL somewhere already)? - Xavier is the only one that takes care of the infrastructure (don't count me, I don't want to do it the infra things I do now and then); that's bad and needs to change; we actually had one or two (maybe more) serious offers from people that wanted to help, but nothing happened, which afaics was at least partly our fault - we have only one person that has access to the signing keys, their pass-phrase and the buildserver; that makes some things easier (no coordination needed), but is a single point of failure (/me wonders why nobody yelled yet about this; seems nobody is interested in things like that, which might mean that this mail likely won't get much attention either). We at least should have one (better: two) additional signers (they of course need to be trustworthy; being on IRC a lot would make coordination easier) -- ideally at least one of them should be located in a timezone that is a bit away from Europe - knurd is also the signle point of failure for the buildsys, as only he has access to the actual builders; that will be changed for one of the x86 builders soon; - thias (who sometime is hard to catch) is the only one that can change DNS in case that's needed - pushing the free repo can take quite some time (an hour? never measured the exact time); would be nice to speed things up (NFS might be the bottleneck that slows things down), but that's just a detail - a good bunch of mirrors and a nice infra to manage them; what are those metalink urls that fedora recently started to use for the alpha? should we use those in the future as well? - parts of the wiki need a cleanup; ideally somebody would constantly watch and take care of the wiki as a whole - some of our processes are afaics not documented at all or not properly documented - documentation in general: there are lots of FAQ, Howto and other docs on the net that describe how to use RPM Fusion; often those are misleading, not fully right, outdated or they disagree with each other; should we try to not only be the inoffical official 3rd party repo for Fedora, but also be the offical 3rd party source for all the docs that can't go straight to Fedora? - there is a small steering committee, but that doesn't meet and until now was rarely used; having a real one (or simply a loose group of people that want to improve RPM Fusion) that regularly meets on IRC could help bringing the project as a whole forward - some ideas for new repos were mentioned (staging; unstable; someone iirc also mentioned the idea to get kde-redhat under the hood, which could have benefits for both sides), but nobody drove those ideas forward - still lots of other 3rd party repos out there; users still run into problems as they try to mix incompatible repos; should we actively try to get more repos merged into RPM Fusion? - rpmfusion-buildsys broken; no announcement mailing list; no real planet or other things to get important information out to the users - out graphics
Re: Where we are and where do we what to go?
Thorsten Leemhuis wrote: Hi! It afaics can help a lot to now and then step back for a moment and try to look with at where we are some distance; after that it's often the time to think about where we want to be in one, two or five years from now. I tried to do that over the last few days; find my thoughts below. Great! = Where we are = - we started a few months ago and it worked out quite well afaics; right now the repos and the packages in it might not be perfect, but the repos overall were and still are in acceptable good condition Yes I'm quite happy with things how they are :) - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher Your to critical I'm quite happy with the steady trickle of new contributers, welcome all! - activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started :-( we just do business as usual, which might be very dangerous in the long term True, but for the most part that is because things are in a reasonable state, I must agree there are some things below which we should work on. - no automatic dep check script running that makes sure our repo is in a sane state; that is something we really need! Yes we really need that, wasn't someone looking into that, so who do we nag? - EL repo: We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of release manager (I'm doing that job a bit for the Fedora repos; someone else, that actually uses EL more than I do should do it for EL; BTW, where did all those go that were interested in supporting EL as they maintained their own rpmfusion/livna rebuilds for EL somewhere already)? Not voluntereering to release manage this, but I do think an EL repo would be good, when I've some time I want to push gstreamer-* there. - Xavier is the only one that takes care of the infrastructure (don't count me, I don't want to do it the infra things I do now and then); that's bad and needs to change; we actually had one or two (maybe more) serious offers from people that wanted to help, but nothing happened, which afaics was at least partly our fault Yes we seem to have a number of SOF on the human side, we need to fix that :) - we have only one person that has access to the signing keys, their pass-phrase and the buildserver; that makes some things easier (no coordination needed), but is a single point of failure (/me wonders why nobody yelled yet about this; seems nobody is interested in things like that, which might mean that this mail likely won't get much attention either). We at least should have one (better: two) additional signers (they of course need to be trustworthy; being on IRC a lot would make coordination easier) -- ideally at least one of them should be located in a timezone that is a bit away from Europe - knurd is also the signle point of failure for the buildsys, as only he has access to the actual builders; that will be changed for one of the x86 builders soon; - thias (who sometime is hard to catch) is the only one that can change DNS in case that's needed Yes even more SOF's we need volunteers here! (not me I'm only a package monkey :) - parts of the wiki need a cleanup; ideally somebody would constantly watch and take care of the wiki as a whole Well kudos to Andreas for atleast keeping it somewhat sane, thanks Andreas, oh and also thanks for all the review work! - documentation in general: there are lots of FAQ, Howto and other docs on the net that describe how to use RPM Fusion; often those are misleading, not fully right, outdated or they disagree with each other; should we try to not only be the inoffical official 3rd party repo for Fedora, but also be the offical 3rd party source for all the docs that can't go straight to Fedora? Maybe for some things, but I wouldn't want to claim we are the cannot be answered by Fedora FAQ answerer, and then in the FAQ say there are lots of 3th party repos, and you should only use rpmfusion. - there is a small steering committee, but that doesn't meet and until now was rarely used; having a real one (or simply a loose group of people that want to improve RPM Fusion) that regularly meets on IRC could help bringing the project as a whole forward Ack, I'll happily give up my seat / disband the whole current committee if there are some people who want to really do this on a regular basis. - some ideas for new repos were mentioned (staging; unstable; someone iirc also mentioned the idea to get kde-redhat under the hood, which could have benefits for both sides), but nobody drove
Re: Where we are and where do we what to go?
On 1/25/09 1:33 PM, Thorsten Leemhuis wrote: Hi! = Where we are = Where we are now is a good start and if we continue on the same track, I think things are only going to get better... - we started a few months ago and it worked out quite well afaics; right now the repos and the packages in it might not be perfect, but the repos overall were and still are in acceptable good condition - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher - activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started :-( we just do business as usual, which might be very dangerous in the long term - no automatic dep check script running that makes sure our repo is in a sane state; that is something we really need! I'm interested in doing this, but I'm not sure when I'll actually be able to get around what the requirements wrt the build system are. IIRC somebody linked to a python script that did this on fedora-devel-list not so while back, maybe we can use that. - EL repo: We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of release manager (I'm doing that job a bit for the Fedora repos; someone else, that actually uses EL more than I do should do it for EL; BTW, where did all those go that were interested in supporting EL as they maintained their own rpmfusion/livna rebuilds for EL somewhere already)? Slightly offtopic, but part of the Wiki revamp should also include docs for how to maintain a packages in the EL repos... - Xavier is the only one that takes care of the infrastructure (don't count me, I don't want to do it the infra things I do now and then); that's bad and needs to change; we actually had one or two (maybe more) serious offers from people that wanted to help, but nothing happened, which afaics was at least partly our fault - we have only one person that has access to the signing keys, their pass-phrase and the buildserver; that makes some things easier (no coordination needed), but is a single point of failure (/me wonders why nobody yelled yet about this; seems nobody is interested in things like that, which might mean that this mail likely won't get much attention either). We at least should have one (better: two) additional signers (they of course need to be trustworthy; being on IRC a lot would make coordination easier) -- ideally at least one of them should be located in a timezone that is a bit away from Europe - knurd is also the signle point of failure for the buildsys, as only he has access to the actual builders; that will be changed for one of the x86 builders soon; - thias (who sometime is hard to catch) is the only one that can change DNS in case that's needed - pushing the free repo can take quite some time (an hour? never measured the exact time); would be nice to speed things up (NFS might be the bottleneck that slows things down), but that's just a detail - a good bunch of mirrors and a nice infra to manage them; what are those metalink urls that fedora recently started to use for the alpha? should we use those in the future as well? According to http://metalinker.org, it combines FTP, HTTP and P2P capabilities together for extremely fast download speeds, along with error checking and redundancy (if mirrors are bad, it can skip them + move on). - parts of the wiki need a cleanup; ideally somebody would constantly watch and take care of the wiki as a whole - some of our processes are afaics not documented at all or not properly documented I've been wanting to bring this up - I think our /Contributors page needs some parts rewritten, and a bit more added in certain spots. We should also create a page with guidelines specific to RPM Fusion (kmods should be mentioned and licensing also comes to mind so we don't have libdvdcss all over again). Also, I don't have a tremendous amount of experience using CVS so I may be completely wrong, but getting the CVSROOT right is annoying; I've put the following in ~/.bashrc to help: * alias plague-client-rf='PLAGUE_CLIENT_CONFIG=~/.plague-client-rpmfusion.cfg plague-client' * alias cvsf='export CVSROOT=:ext:usern...@cvs.fedora.redhat.com:/cvs/extras' * alias cvsrf='export CVSROOT=:ext:usern...@cvs.rpmfusion.org:/cvs/free' * alias cvsrnf='export CVSROOT=:ext:usern...@cvs.rpmfusion.org:/cvs/nonfree' Maybe we should include this too in /Contributors? - documentation in general: there are lots of FAQ, Howto and other docs on the net that describe how to use RPM Fusion; often those are misleading, not fully right, outdated or they disagree with each other; should we try to not only be the inoffical official
Re: Where we are and where do we what to go?
Hans de Goede wrote: Thorsten Leemhuis wrote: ... = Where we are = - we started a few months ago and it worked out quite well afaics; right now the repos and the packages in it might not be perfect, but the repos overall were and still are in acceptable good condition Yes I'm quite happy with things how they are :) I agree with that. Do our users agree ? - can we count how many users we have ? - can we count how many updaters we have ? - could we get such info from the mirrors ? - before the above, do people consider getting such info out of web logs to be an invasion of privacy ? - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher Your to critical I'm quite happy with the steady trickle of new contributers, welcome all! And for most serious packages, it is not a breeze to bang up a .spec and get it reviewed (mine took around a year from my first work on a spec until finally ready for inclusion). But I far prefer this than having a zillion app users configure, make, make install packages they find on the net. We do need to ensure that all reviewers do so in a positive frame of mind, rather than being abusive or dictatorial in their responses. We don't want the packager to be put off, neither do we want other readers of the review (eg from a mailing list archive when a user does a search for something) to think that being part of the RPM Fusion sounds bad / is a stress etc. - activity to improve the project as a whole (not meaning the repo or the individual packages) went down a lot since we started :-( we just do business as usual, which might be very dangerous in the long term True, but for the most part that is because things are in a reasonable state, I must agree there are some things below which we should work on. We could look at this as what would make rpmfusion the 'killer app' that essentially every user immediately enables after a fedora upgrade or install ?. - dvd playback ? - mp3 playback ? - closed source graphics driver support ? - EL repo: We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of release manager (I'm doing that job a bit for the Fedora repos; someone else, that actually uses EL more than I do ... Not voluntereering to release manage this, but I do think an EL repo would be good, when I've some time I want to push gstreamer-* there. For me, I don't use centos/el anymore at work nor home, so I'm reluctant to build something for it, since I don't really know the differences, and (if we don't already) we should have some info regarding such differences, update mindset, stability mindset of the people that use EL. One way could be to give a time frame of say 60 days from the EL release or major update (or even maybe fedora release, since it seems common for about a gigabyte of Fedora and RF updates to be needed within a month or two of a Fedora release) to have completed integration repo testing and then what is ready becomes the rpmfusion release for that version. Other things I don't know about EL: - do the public have access to a continual stream of rawhide packages like fedora ? - do the public have access to beta releases ? should do it for EL; BTW, where did all those go that were interested in supporting EL as they maintained their own rpmfusion/livna rebuilds for EL somewhere already)? Perhaps it is too easy to createrepo and publish somewhere on the web. I think there is also some kudos involved like - what experience do you have admining linux systems? - I built and maintained an rpm packaging repo for 20 packages. There is possibly also some issue of trust eg: if I am using EL for work, then I might need to guarantee any packages used are of sufficient quality and free from potential exploits etc. The only way I can do this is get the source and build it myself. ie there is no RedHat support saying this package is good. How would you build such a reputation for RPM Fusion ? I think the best bit about packaging for Fedora or RPM Fusion is the interaction with reviewers. This can help a packager go from 'this seems to work for me' to 'this works for at least two people possible on different architectures' to 'this is a much better package now that more eyes have been across it'. Even the comments from brand new packagers /reviewers are helpful to pick up things that I have missed. - Xavier is the only one that takes care of the infrastructure (don't count me, I don't want to do it the infra things I do now and then); that's bad and needs to change; we actually had one or two (maybe more) serious offers from people that wanted to help, but nothing
Re: Where we are and where do we what to go?
On 25.01.2009 20:07, Hans de Goede wrote: Thorsten Leemhuis wrote: [...] - since we started we got some new packages and a few new contributors; that's good, but in fact I had hopped the numbers of new contributors would be a little bit higher Your to critical I'm quite happy with the steady trickle of new contributers, welcome all! Sure, I'm happy as well, I just had hopped for a bit more ;-) [...] - no automatic dep check script running that makes sure our repo is in a sane state; that is something we really need! Yes we really need that, wasn't someone looking into that, so who do we nag? I think Xavier once offered to look into that -- I remember I then stopped to look closer into this myself. Getting it to work is likely not that much of a deal, someone with the proper rights on the buildsys likely just needs to sit down and do it. - EL repo: We need to decide if we let this lift of or drop it now before it started for real. Yes, some packagers like the idea and maintain their packages for the repo, but that's not enough for a repo to last; for the EL repo to really lift of we need someone that takes care of it as kind of release manager (I'm doing that job a bit for the Fedora repos; someone else, that actually uses EL more than I do should do it for EL; BTW, where did all those go that were interested in supporting EL as they maintained their own rpmfusion/livna rebuilds for EL somewhere already)? Not voluntereering to release manage this, What I forgot to say: I'm willing to help with this. But someone else really needs to have the official hat on. That imho should also include to look at the usual channels and lists to watch out for problems users might run into. but I do think an EL repo would be good, strong +1 when I've some time I want to push gstreamer-* there. thx [...] - there is a small steering committee, but that doesn't meet and until now was rarely used; having a real one (or simply a loose group of people that want to improve RPM Fusion) that regularly meets on IRC could help bringing the project as a whole forward Ack, I'll happily give up my seat / disband the whole current committee if there are some people who want to really do this on a regular basis. I fear a bit that a new steering committee might revisit the libdvdcss issue immediately. That could bring the project into serious trouble, which I'd really like to avoid. It also would be kind of unfair if that decision would be changed quickly, as some people that invested a whole lot of time in RPM Fusion (like me) only did so because libdvdcss was left out. - some ideas for new repos were mentioned (staging; unstable; someone iirc also mentioned the idea to get kde-redhat under the hood, which could have benefits for both sides), but nobody drove those ideas forward I think that would spread us to thin, focus is important, I think it is important we define out goals clear, see below. Sure, there are risks. But it could bring lots of new contributors and help to get 3rd party repos merged into RPM Fusion. Especially the latter is appealing IMHO. [...] - out graphics driver packages seem to have not a real good reputation: users accidentally remove the stuff that is needed in xorg.conf with tools like ati-config, nvidia-xconfig, ... and hence break the drivers. Users are also confused by the different drivers; many don't know which one to choose (legacy, 96xx, 173xx, beta, ...) I recently accidentally got a system with an nvidea, and the packages are excellent, what we need is docs and PR. Sorry, I totally disagree here. If something requires docs to be used then it's IMHO partly broken already. Just Look at fedora-list, where especially in the october/november/december timeframe a lot of people run into problems with our drivers. Further: I also saw three of my colleagues (one quite familiar with Fedora; the other two not so, but they are real Linux experts) try to use the drivers. All of them failed somewhere and all ran into different problems. But yes, work is done to make things better. But there is still a lot of work to do afaics. - RPM Fusion packages with hard deps on Fedora packages (kmods, xine, qmmp, audacious, ...) often create lots of problems for Fedora users due to mirrors lags (RPM Fusion mirror might be have a newer xine-lib-extrs-nonfree while the Fedora mirror yum doesn't have the matching xine-lib yet or vice versa; details: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html ) we really need a solution for this, but I don't know how and my questions how to fix this seemed to get ignored by skvidal :-/ This might be one of those things which we just cannot fix a 100%, maybe we should learn to live with it? No, this can't be fixed 100%, but it can be made a lot better, as most of the times things are on the servers -- yum just chose not-up2date mirrors. Maybe a yum plugin could do
