Board efforts: scope, concept, and permission?
jkeating at redhat.com
Tue Feb 2 21:11:47 UTC 2010
On Tue, 2010-02-02 at 14:36 -0600, Adam Miller wrote:
> On Tue, Feb 2, 2010 at 2:29 PM, Bill Nottingham <notting at redhat.com> wrote:
> > Take a random downstream app. (Firefox is an example, but there are many
> > others.) Right now, it only needs to track a single version of python,
> > or a single auth framework, even if it may be used on any desktop or any
> > spin. The implication is that in some sort of future with SIG-specific
> > conflicting frameworks, this downstream app maintainer now must be familiar
> > with, and handle *all* of the frameworks, even though they're not
> > specifcally a part of any SIG. That's sort of a rotten thing to do to
> > Joe Random Maintainer.
> > You could say that the SIG needs to then supply people to handle every
> > potential downstream app, but that's also not nice, and is going to lead
> > to fun coordination with updates.
> I don't think that's an issue either, I'm not proposing we change
> anything such that it could cause problems. I'm saying the way things
> are now works and I don't understand the desire to change it.
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.
Status quo is hard to define though, and hard to measure. So instead of
trying to capture what the status quo is, where every package maintainer
is essentially free to design their package however they see fit (within
the package guidelines), instead we'd like a general idea of what the
status quo should be. A project level idea of what type of things our
packages should target. That will help people decide whether or not
their spin can be done within those constraints, or if they have to go
the way of a remix to accomplish their goal. Right now they don't have
any guideline and are left to discover things on a package by package
basis creating conflict as they go.
Fedora -- Freedom² is a feature!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100202/874f6d26/attachment.bin
More information about the devel