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