RPM submission procedure

Jef Spaleta jspaleta at princeton.edu
Thu Jan 8 05:14:24 UTC 2004


Eric S. Raymond wrote:

> These both seem like readily solvable problems to me. 

I'm of the opinion that some issues are complex enough to allow for
perfectly valid and completely opposite points of view. And I'm also of
the opinion that some issues are dominated more by historical precedent
and "i was here first, automatically respect my claim on mindshare in
this space" attitudes than on sound logic and a willingness to
compromise on arguable less important priorities to meet the most
important priorities. And I'm of the opinion that sometimes people just
can not agree on what the priorities are. 

So lets get down to to it shall we? Let's look at the history of the
repository space. Red Hat, in the past, for reasons of their own, have
neglected to foster any sort of policy or guidelines about how 3rd party
repositories should be structured. As a result what sprang up has been a
very fractured collection of one person or very small group efforts to
provide a needed community service to provide additional packages to the
userbase. Some have become quite popular and to their credit became
popular because they did indeed have a measure of quality in their
packaging that the userbase grew to respect..but the fact is, it was a
very fractured landscape, leading to real package conflict problems
across repositories, and end-user difficulties when trying to reach out
and get all the packages they wanted, from multiple repos.  I would
describe the situation as loosely related bands of nomadic tribes of
packages. Sometimes their were inter-tribal marriages and sometimes
there where blood feuds.  

I'm not going to take anything away from someone who is able to build
500 packages and place them into a repository and build a userbase. That
is an accomplishment of merit. But its not a community effort. 2 such
people who have the ability to build their own 500 package repository as
they see fit is not a community...neither is 5 or 10 or 20 or 40 or 17
billion. A community effort MUST have guidelines and policies to follow
and their MUST be peer review, and a sense that interested people can
walk into the process and learn how to be active in it, a way to mentor
such people and teach them how to do things in the best ways following
best practices and a sense that they can earn a place in the process.
There needs to be a sense that if one person steps out of the process
for whatever reason the community effort will continue. There must be a
sense that everyone involved is valued...but not indispensable. An
archipelago of one man repositories doesn't really convey this sort of
sense of community. If for some reason, god forbid, Dag had to stop
producing packages for personal reasons, that's a big blow to the
archipelago concept since there are no written policies that I know of
that others can follow to reproduce what he has accomplished.         

I'm not a scholar of the history, but the first noteworthy example I
noticed of defining ANY packaging and QA standard for Red Hat rpm repos
was fedora.us. It's pretty clear to me that fedora.us policy that we see
now, has prioritized around the concept of building an actual community
process that in the long run can be reproduced and re-implemented from
the written policy guidelines....and not from a cult of personality.
 
And now we come to the crux of the issue. Coming to a consensus among
ALL the interested parties about what the actually priorities are in the
process pretty much defines what the packaging community is going to
look like:
How transparent do the QA processes NEED to be? 
How much input from the community does there NEED to be? 
How hard do you want to try to make sure all the packages meet the same
level of quality? 
How important is it to make sure all the packagers are using common
conventions and best practices when writing build scripts?

And i see the current split in the world views as coming down to
prioritizing the first couple of questions in the list. Fedora.us ranks
transparent QA and the NEED (not just a token desire) for community
input on how packages are built very highly.  I don't see the one man
repository islands making these things a priority. And thus, the
discussion can not get past that split in world views. If people in the
discussion can not agree on the priorities...there is a clear difference
of opinion at the basic level of belief at how the world is suppose to
work. Pretending that you can get people who have VASTLY different
priorities to come together for a consensus is a foolish naive dream.
I'm pretty sure its been stated already somewhere in the fedora lists,
that there was internal Red Hat debate about joining debian, but because
the list of priorities as Red Hat understood them differed significantly
from the priorities debian has...we have the Fedora effort instead.

And in a not so dissimilar way, we stand now with 2 opposing view about
what community packaging should look like. The pre-existing archipelago
of one made repos loosely working together with community input welcome
but not really necessarily. And the 'new' concept of fedora.us which
places a HIGH value on making community involvement as part of the
packaging process a priority. Different world views....and i would
strongly argue that a continued refinement of how fedora.us tries to do
things is in the long run the stronger more robust community process. A
process that not only creates high quality packages, but provides a
clear way for new and interested community participants to get engaged
and invovled and to mentor them so they learn via communication with
other community members how to do packaging better. It provides strong
lines of communication so that best practices in regard to how to
package things are not horded by the 'professionals' as a secret sauce
knowledge but focuses instead of making it possible to document those
best practices so that new people can learn them.   

Is there room for improvement on how the fedora.us policies work... of
course. But to make constructive forward looking changes to the process,
you have to value the core objectives that the fedora.us process is
trying to meet. And in my mind the core objective for the fedora.us
process is not to package up the world as quickly as possible...the
focus is on building and documenting a community process for building
high quality packages that other people can follow and use as a
guideline.  And I personally think if the new Fedora Extras process
doesn't continue to make transparent QA a priority...and doesn't
continue to demand community involvement as part of the packaging
process, but instead allows 'trusted' packagers to do whatever they want
without peer review....the overall Fedora effort will be losing a very
good process for educating and mentoring NEW community members who want
to get involved with packaging. A community process NEEDS to be as much
about educating and mentoring NEW community members so they can continue
on with the work..as it is producing a work at all.

-jef"and that was me trying to be nice..."spaleta

   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040108/5c53cb4b/attachment.sig>


More information about the fedora-devel-list mailing list