This email was first sent to fedora-devel as a followup to the
"Definition of Open Source" thread. Perhaps it got lost there, because
I only saw a few responses, followed by dozens of emails on the subject
it treads under the heading "Core Size Reduction". This re-post is an
attempt to get people to read and respond to these ideas.
Now, let me say that this is /my opinion/. Despite the @redhat.com
address, this is not Red Hat's position, it's mine. Second, this is a
/preliminary attempt/ to organizing a wide range of thoughts that I've
been seeing across this list over the past 2-3 weeks.
I half expect that this will get shouted down, perhaps by people sitting
near me, but if it's a step in the direction of separating and solving
the issues that this discussion has touched, I'm happy to take it as far
as I can.
Two words about the diagram: I think that Seth Vidal's recently posted
Fedora submissions process was a great start, but it did not reach far
enough. This diagram attempts to show how actors within the community
can draw from the universe of available packages and place them into
some meaningful Fedora context. Second, I now know that Seth wasn't
trying to answer the question of attracting new package submissions.
However, for Extras, that's really important, and I am.
Finally, while Notting's suggestions about how to reduce the size of
Core may explain how Red Hat has done it in the past, that's not the
only possible approach. One could certainly take an opposite approach
of trying to build a minimal set of packages and then incrementally add
to them. Red Hat probably took the approach it took because (1) that's
how we've done it historically, and (2) we had only one chance to get it
right, and that seemed like the best way to go. However, with a large
community, many possible approaches can and should be tried. I would be
delighted to see many competing approaches to selecting packages for
various collections, something that might help us find combinations that
are more optimal for a given purpose but whose path of discovery may be
too political/contentious for Red Hat to follow on its own. In short, I
think that writing a charter for a collection and a repo definition that
implements that charter is a better approach than talking abstractly
about what should or should not be in a collection whose charter has not
been published. This strawman attempts to make some definitions of Core
and Extras that may be effective.
Shameless plug: I'll be at OSCON this week, so anybody who wants to
discuss this in person can do so this week in Portland.
M