Collaboration

Tim Jackson lists at timj.co.uk
Sun Apr 29 12:32:20 UTC 2007


Dag Wieers wrote:

> On Wed, 25 Apr 2007, Tim Jackson wrote:
> 
>> 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.
> 
> EPEL is not independent. EPEL is Fedora is Red Hat.

You missed my point. I wasn't talking about independence in a 
political/organisational sense. I simply meant that it is a standalone 
repository/project.

>> b) Because the standards, processes etc. of the repos are different and
>>    therefore, as we have already established, they are serving different
>>    purposes
> 
> What is ironic, is that the standards are based on common practices that 
> all the repositories created as part of the packaging community. 

That may well be the case. In that case your beef is (mainly) with the 
individual package contributors who either ignored or didn't bother to 
check existing packages to see if there was a way to "play nice" before 
redesigning a package. This is not a failure, per se, of Fedora, but is 
a result largely of human nature, though the project as a whole of 
course has to take responsibility.  Although we try to present a unified 
face, no project would exist without the people that contribute to it. 
So, we need to move the discussion away a little bit from "How Fedora 
communicates with other repos" and more towards "How the intelligent 
people that contribute to Fedora communicate with the intelligent people 
that package stuff in other repos". As you rightly imply, no amount of 
policies or processes will substitute for good old fashioned 
person-to-person co-operation.

There is however still the fact, as I've pointed out before, that there 
isn't always an empirically "correct" answer to a problem. There may be 
two incompatible but equally valid ways to package something. That said, 
I do agree that in the absence of compelling and observable 
improvements, given two competing solutions it would be better to stick 
with the existing one for compatibility. I'm 100% behind you on that.
(I'm commenting in general here, rather than specifically about clamav; 
whether or not clamav in Fedora is a compelling improvement over clamav 
in RPMforge is a discussion for another time).

Actually, due to differing goals, there will probably be times where 
there simply is no way to produce one package that meets criteria for 
both Fedora and [other repo]. In that case, we may just have to accept 
that (and do what we can at a technical level to make things as 
compatible as possible, e.g. via Requires/Provides). However we should 
all work hard to make those cases as rare as possible, ideally zero.

> And back then Fedora stepped in, and redid everything. They could of 
> course because they made the OS, so they would have authority as well for 
> the add-on stuff.

I think you're ascribing higher authority and motives here than actually 
exist. The problem here is communication, plain and simple. "Fedora" 
didn't make the clamav package, a person did. If the clamav packager 
didn't look at what other packages were already around, and discuss 
possible changes with other well-respected maintainers before making the 
Fedora package, then that's regrettable IMHO, and of course I understand 
why you, Dag, might feel a bit miffed. (If he did, but the disagreements 
couldn't be resolved, then that's a slightly different matter as I 
discussed above). I don't think it helps anyone (including Fedora/EPEL) 
to reinvent the wheel unnecessarily; we should all be trying to build 
the best solutions. Which is exactly why I think collaboration is very 
important. To reiterate though, this is a 2-way thing and if a Fedora 
packager suggests changes/improvements to you, I would expect you to be 
receptive to those in the same way that I would expect the packager to 
be receptive to building packages that are compatible with existing ones 
from you.

> If EPEL is not the Master 3rd party repository, then please start to look 
> if what EPEL introduces is compatible with what already exists. Because 
> the clamav packages surely don't play nice with what already existed.

On this topic we both agree.


I do understand why you are suspicious of EPEL, and I can't blame you 
for that based on some bad experiences with specific Fedora packages.
However, as you can see, I think the views of you (Dag) and me (Tim) are 
actually very closely aligned, and whilst I can't speak for other 
contributors, it isn't my impression that my opinions are wildly 
different to other people's. So that's why I think it would be a shame 
for you to dismiss EPEL/Fedora entirely when actually with a small 
amount of work from both sides, we can probably reach a solution that 
suits everyone. It would be much better to work together instead of 
fighting, because then we can focus on the real goal of making packages 
that help people get real work done as simply and easily as possible.
We won't always agree 100%, but that's OK as long as we keep the bigger 
picture in mind.


Tim




More information about the epel-devel-list mailing list