December 2010 Fedora Election Plan

Jeroen van Meeuwen kanarip at kanarip.com
Thu Oct 28 11:36:33 UTC 2010


Toshio Kuratomi wrote:
> On Wed, Oct 27, 2010 at 07:40:37PM -0600, Stephen John Smoogen wrote:
> > On Wed, Oct 27, 2010 at 19:00, Jeroen van Meeuwen <kanarip at kanarip.com> 
wrote:
> > > Matt Domsch wrote:
> > >> I'm sensing a growing frustration from some of the people who have
> > >> been heavily involved in Fedora for a long time, a sense of burnout.
> > >> We've all felt it from time to time.  The lack of people stepping
> > >> forward to take on leadership tasks, such as the Spins SIG leader, the
> > >> election coordinator, and similar is concerning to me.  Am I alone in
> > >> this?
> > > 
> > > No you're not.
> > > 
> > > I can't explain why concisely but Fedora was and is no longer an
> > > awesome engineering platform where I could Get Things Done.
> 
> Actually, I think this pretty concisely describes my burnout.  It's getting
> harder and harder for things to get done.  (Yes, I realize this coming from
> the person that has to play the bad guy about bundled libraries all the
> time keeping packages out but... I've recently asked if we should relax
> those guidelines since it seems that no one wants to enforce them
> consistently.)
> 

Wow, this is huge;

We all know *why* our guidelines and rules set out the boundaries of the road 
to salvation, and they *are* superior to any other distribution. Really, I 
think they do and that they are. We have the most savvy people in this world 
working on these things continuously, and while I may not understand some of 
them, I trust these people. I think we should stick with them guidelines as 
much as possible. "As much as possible" being the key words in that sentence.

We seem to lack the willingness to seek compromise in many aspects; case in 
point here is bundled libraries, but more in general we seem to lack the 
formerly existing attitude of "Hell yeah. How?" - I'm afraid it has become 
"Why? If ..., and if ... Euh... No."

Example case in point is rubygem-passenger, shipping a bundled, forked and 
modified legacy version of the boost C-library. Bad, bad, bad.

I can't fix it. I'm a terrible C coder. Nobody looking at reviews can fix it 
before the end of dawn, and only after it's fixed it would be accepted as a 
package.

This means that meanwhile, thousands of us downstream consumers run rubygem-
passenger customly built, packaged (maybe) and deployed to production, 
whatever was the latest version when someone had a chance to look for updates. 
Bad, bad, bad. Very bad.

I think a better sustainable route is to allow the package to get in, and log 
massive amounts of bugs against it to fix what would then be ending up on 
many, many systems; The effect is downstream consumers run in circles less and 
less because they do not have to build and deploy the foo on their own and the 
Fedora Project (or the Red Hat Bugzilla) becomes the tip of the point of all 
that momentum. *I* think that's worth balancing off road-to-salvation-
guidelines vs. actually-might-get-it-done-proper.

However, more relevant to my previous post; If I had the slightest impression 
I could improve this in the Fedora Project, hell I'd run for FESCo with solely 
this agenda item. I've not ran for FESCo, so guess what my impression is.

Fedora Project may not even know or ever hear its throwing up roadblocks 
simply by de-motivation on the account of prior roadblocks having been thrown 
up whether any individual within the project or the project itself thinks of 
these as actual roadblocks.

Yes, it's mostly eager, savvy, renegade, stubborn, visionary and/or more 
established contributors running into these kinds of things -but it's also the 
group of people you can safely assume will do the right thing given a level of 
compromise to be sought or dare I say it, free reign.

Kind regards,

Jeroen van Meeuwen
-kanarip


More information about the advisory-board mailing list