Board efforts: scope, concept, and permission?
a.badger at gmail.com
Wed Feb 3 02:38:38 UTC 2010
On Tue, Feb 02, 2010 at 07:52:55PM -0500, Josh Boyer wrote:
> On Tue, Feb 02, 2010 at 05:16:14PM -0500, Toshio Kuratomi wrote:
> >On Tue, Feb 02, 2010 at 01:11:47PM -0800, Jesse Keating wrote:
> >> The way things are now "works" because of status quo. We tell anybody
> >> who wants to change status quo to go start a fork and do it there.
> >Wait... The entire list of times I can remember someone being encouraged to
> >take their contributions elsewhere are:
> >1) Kernel modules
> >2) Non-free software
> >3) Free software with legal issues
> >4) I think something to do with packaging content may have resulted in
> > something but I don't know anything about the outcome there.
> >Who's been told to fork Fedora because of the status-quo-target-audience?
> Not in so many words, but the whole Zope/Plone fiasco from a few releases
> ago seems a prime example here. Fedora moved on with python, and we didn't
> allow a compat-python package for Zope and Plone to continue working. The
> reasons were varied, but they boiled down to python being a framework and
> having two frameworks providing almost identical things was not deemed to
> be something Fedora was going to do .
Once again, not a target audience decision. We didn't say, "Fedora is not
for web developers, therefore we don't care enough to support zope and
plone". We said, the python maintainer thinks that supporting multiple
python stacks is infeasible therefore we aren't going to support this. It
was a contributor and technical decision. Not a target-audience decision.
(Also note, I fell on the losing side of that discussion as well :-)
> Those are the kinds of headaches Bill is talking about.
And I agree there are headaches there. But I think if something is valuable
enough to a contributor, they'll step up to solve the headaches if they're
requisites to being able to fulfill their vision. Instead of forbidding
things we should be identifying the headaches and allowing them
After all, everything we do now is one big headache. Yet we have
contributors willing to deal with every aspect of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100202/f11b0226/attachment.bin
More information about the devel