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@xxxxxxxxxx> 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].
