Collaboration

[Tim Jackson]

Johnny Hughes wrote:

> If RPMforge has a perfectly working ClamAV for EL5, and if we are
> collaborating, why would EPEL build ClamAV?

a) Because EPEL is independent, and should have infrastructure which is
   independent of other entities. This is a basic principle of running any
   self-contained project. It does NOT exclude collaboration, unless your
   definition of "collaboration" is particularly narrow.

b) Because the standards, processes etc. of the repos are different and
   therefore, as we have already established, they are serving different
   purposes

> Answer to both ... EPEL wants to be "THE" Master 3rd Party repo, not
> just a 3rd Party Repo.  There can be no misinterpreting that, it is just
> plain fact.

As an existing user of various repos including Dag & AT, a tentative
contributor to EPEL (following FE) then I'm still not sure that that's
true and it's definitely not "fact". However, I do believe I understand
why you might feel that way - in fact I had a lengthy and good-humoured
discussion in person with Dag about this very topic at Linux World last
November.

BEFORE READING THE FOLLOWING PARAGRAPHS, READ THEM **PROPERLY**, DO NOT
INFER THINGS THAT AREN'T THERE AND DO NOT EVEN CONSIDER FLAMING ME
UNLESS/UNTIL YOU HAVE READ THEM PROPERLY AND UNLESS YOU RECOGNISE THAT I
POSITIVELY AND EXPLICITLY ***LIKE*** DAG/ATRPMS/KB/CENTOS etc.

What *I* see is that EPEL has a collaborative element that *in my opinion*
is lacking (or at least lacking visibility) to a lesser or greater extent
in other repos. That's **not** a criticism, it's an observation. What I
mean by this is that, to a large extent, "Dag repo = Dag Wieers", and
"ATrpms = Axel Thimm". I could be wrong, but I don't think that Dag, Axel
et al. have the kind of procedures, processes, open contributory model
etc. that EPEL effectively already has (based on the excellent work of
Fedora Extras). Nor do I see that they're likely to grow that any time
soon. Let's look at some examples (THIS ***IS*** ***NOT*** bashing of
other people's efforts. I cannot emphasise that enough. It is just a
superficial look and an attempt to bring this discussion onto some
concrete ground)

RPMforge
http://rpmforge.net/manifest.php is fine, but it's 1 page.
http://rpmforge.net/packager/ is minimal at best. "Documentation" is a
non-existent link from it. http://rpmforge.net/packager/persona/ indicates
that it is still just 3 people. None of this has changed significantly to
my recollection since RPMforge.net was set up some time ago. I don't see
an easy or visible way for me as an outsider to get involved at a genuine
peer level.

Karanbir
http://centos.karan.org/ has effectively zero docs, and invites all
contributions to be directed at Karanbir personally. This has not changed
significantly to my recollection since the start. I don't see an easy or
visible way for me as an outsider to get involved at a genuine peer level.

CentOS
http://www.centos.org/  (Information -> Team -> Members) suggests that
CentOS Extras is a 1 person effort by Jim Perrin. "Wiki -> Contribution
Policy -> Packages" is a 1-pager which tells you how to contribute to the
"contrib" repo (not Extras or Addons), and that "contribution" appears to
involve passing stuff to someone else, rather than playing an active role
yourself. I don't see an easy or visible way for me as an outsider to get
involved at a genuine peer level.

Fedora/EPEL
http://fedoraproject.org/ has hundreds of pages of largely high quality
content, contributed by multiple people. It's not always organised or
perfect, but it does have tremendous depth from high level/policy issues
to low level technical things. It has an open infrastructure, SIGs and a
huge base of contributors. It's easy for me as an outsider to see the road
towards being involved at a genuine peer level.


So, Fedora/EPEL aside, the above projects strike me (rightly or wrongly)
as largely "closed" circles. That's *not* to say the people involved are
not open-minded or not open to help. But the projects appear to be highly
dependent on individuals or very small groups. (This is natural, human,
and not something to be surprised about). On the contrary, FE has an
established and visibly open model which as a project is increasingly
resilient to the disappearance of individuals. (This isn't hypothetical;
we already have examples of significant contributors disappearing and yet
the project continues OK).

Does this make EPEL "better"? Are these things negative reflections on any
of the above efforts? Emphatically NO! Specifically, the above projects do
nothing but reflect immensely well on the hard-working people behind them.
If anything, I think some of the third party repos have the edge,
technically, over Fedora/EPEL due to the exceptional technical skills of
their owners. The lack of process instead, to me, merely reflects the fact
that implementing an open collaborative model is extremely difficult,
*enormously* time-consuming and something that no one person (or even a
small group) can really do alone. Writing policies, setting up
collaboration systems, encouraging others to contribute and dealing with
politics/in-fighting is all, frankly, boring and it doesn't get the day
job done when you can just go ahead and build what you know are great
packages. Heck, that's why I maintain a private repository: I've no way
got enough time in the day to do all that stuff.  What I see in Fedora
Extras (and by extension EPEL) is a project that has enough momentum,
enough "grassroots" interest, and the infrastructure in place to
facilitate a truly open process, and one which I can become incrementally
involved with as I see fit.

Now, some people might think all of the above is just unnecessary
bureaucracy, and they're 100% entitled to that opinion. They may place a
packager's established record and clear personal skill as the #1 priority,
with all other things like documentation, processes, collaborative input
etc. a distant second. On the other hand, some people feel that the
processes are *more* important, that good technical quality will naturally
follow almost as a side effect, and that a clear, comprehensive and
documented collaboration model (with more or less equal access to all
contributors) gives one a sense of confidence that is important
(particularly in an EL environment). So you could see this as more of a
"bureaucracy" debate rather than a "technical" one, and I see that as one
of the potential differences between EPEL and other repos.

> If we were collaborating, EPEL would build things not already in
> RPMforge or ATRPMS or CentOS Extras.  

I disagree in the strongest terms. That's a very superficial and specific
type of collaboration. Collaboration does not mean "only 1 copy of
anything". It means collaborating at an intellectual level (as you
yourself quoted!). The binary packages are just the end output. The
process to get there is where the real collaboration takes place. There
are many other possibilities too: sure, why not make Dag repo the "master"
for the packages that Dag wants to "own", assuming that his policies and
the EPEL policies precisely correspond in respect of those packages? I
would support that. But we should still sync it into EPEL CVS and build it
in the EPEL buildsys. (In many ways like Dag/Matthias/Dries have been
doing with RPMforge, though I'm not sure to what extent their
infrastructure is shared vs independent)

And as I said in an earlier post, "collaboration" means personal
collaboration, not just technical collaboration. Personal collaboration is
the important bit. How that happens technically is an implementation detail.

> Why does that make me even the slightest bit nervous ... I mean, Red Hat
> would never ever pull the plug on supporting Fedora EPEL (Or the
> mythical Fedora EL, if it happened and put CentOS out of business),
> would they?  Of course they would if it enhanced their business model.
> Anyone here ever heard of Red Hat 9?

With an open collaborative process, open CVS, open documentation etc. then
I don't see what's to stop someone else (e.g. CentOS) taking the whole
EPEL thing wholesale tomorrow and continuing the effort even if RH did
decide to back out. I'm not sure what relevance RH9 has; frankly, I think
that splitting RHL into EL and Fedora was the best thing RH ever did (and
no, I'm not an RH employee), but I don't think this is either the time or
place to debate that.


Tim