Taking a break (this time for real) and looking for volunteers that take over my RPM Fusion jobs

Michael Schwendt mschwendt at gmail.com
Fri Dec 17 11:55:15 CET 2010


On Tue, 30 Nov 2010 20:56:50 +0100, Thorsten wrote:

> > Thanks Thorsten for keeping the show alive for some time. :) 
> >
> > I just wish RPMFusion would have had a benevolent dictator (or two or
> > more) with appropriate courage and (first of all, even) decision powers --
> > as is necessary for some things to move forward.
> 
> Actually I might have acted as benevolent dictator here and there, but I
> tried to avoid that most of the time and leave people room, as I tend to
> think a real community IMHO will only form if people are involved
> decision making (that's the long story short).
> 
> Looking back at it I sometimes think it might not have been the best
> solution for a project as small as RPM Fusion :-/

You say "small", but actually the small size of the project has not been
put to an advantage. The switch from livna.org to rpmfusion.org reminded
me of the close-down of Fedora Extras (except that the newly formed Fedora
Infrastructure has had increased requirements as it wanted to handle the
growing number of packagers and packages).

What I've been missing is somebody _to decide_ on the future (and an
agenda) and at the same time tell what exactly *could* be done (read:
contributed). Such as continueing with Plague, but specific releases of
it, and fixing it further if necessary, or modifying it to meet the
current requirements. For example, with regard to updates-testing and
building against updates-testing. Instead, everyone (especially the
packagers) seems to be waiting for koji/bodhi/mash to pop up, and I doubt
there is anybody who could tell how much of that will be feasible. Just
imagine how often bodhi has caused trouble and has been updated/replaced.
Whoever will introduce those tools to the current infrastructure will very
likely need to dedicate additional time on maintaining them. It's kind of
useless to revisit repo compose tools (aka the old pushscripts or multilib
stuff) and improve them or work on alternatives if it's not known what
could be used in production at rpmfusion. Months later, months lost.
The "never touch a running system" principle can also be a hindrance.


More information about the rpmfusion-developers mailing list