[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Collaboration

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

> 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


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)

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.

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.

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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]