Definition of Core, Extras, and more (Fedora Collection Strawman)

Michael Schwendt fedora at wir-sind-cool.org
Mon Jul 26 11:22:39 UTC 2004


On Mon, 26 Jul 2004 06:33:58 -0400, Michael Tiemann wrote:

> 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.

Well, maybe you could post it as a completely new message instead of as a
reply to an old message <40FE2F6A.7080701 at redhat.com> in the thread
"Definition of Open Source...". That would avoid the mail header
references which tie your message to that thread. Currently, your message
is lost among all the replies in that thread, IMO. There are subscribers
who collapse the message in threads they are not interested in, and those
would not see your post.

> Two words about the diagram: I think that Seth Vidal's recently posted

Not Seth, but Ville Skyttä. ;)

> 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.

Details, *please*. What you refer to as "draw from the universe of
available packages and place them into some meaningful Fedora context"
gives a very fuzzy picture only.

There are various other sources of packages, which people from the
community can derive their own packages from. The current problem with new
package submissions is not where to take available packages from, but to
bring the packages into shape and push them through the QA process. This
is a resource problem. If only a single user of a new package would engage
in reviewing the package in accordance with the policies, that would move
the packaging community forward. Because a lot of packages "in the wild"
would either fail to build in the build system, contain various package
bugs or don't even work for users other than the packager himself.

Another issue is the definition of "trust" and what new actors within the
community can do to earn trust. There are different levels of trust. For
instance, if I've worked together with a community member for some time,
believe that he doesn't have bad intentions and have verified that he's
actually the one he pretends to be, it can still occur that I wouldn't
want him being able to publish unreviewed packages because of sloppy
packaging, incautiousness, or daredeviltry [with regard to bleeding-edge
releases].





More information about the devel mailing list