Relationship to existing 3rd party repos/CentOS/SL?

[Tim Jackson]

Axel Thimm wrote:

> the voting/decision on repotags was labeled as being 99% a political
> one, and no one objected against that old statement. 

I don't think that means you can assume it's correct. If I say "the sky 
is green" and nobody bothers to disagree, it doesn't make it so.

> Does the outcome of EPEL not carrying repotags mean that there is no 
 > interest in cooperation with 3rd party repos?

Again, I think you're extrapolating too far here. It seems many people 
are "ambivalent" about the repo-tag thing, myself included. I can live 
with it, I can live without it. I don't really care. (Maybe I should, 
and maybe it's some kind of failure that I don't, but that's how it is). 
I think you're assuming that everyone feels as strongly about this as 
you do (either positive or negative), whereas they don't, and you're 
thus inferring a strong feeling that isn't there, that by not

I am not mentioning repotags again; the rest of this post is referring 
to issues "in general" and NOT specifically repotags.

>  * Will it jump in the game ignoring that 3rd party repos exist and
>    let Darwinism prevail?

I think that any repo that aims to be self-consistent has to effectively 
"ignore" other repos from a strictly technical perspective. Either you 
depend on packages in other repos, or you don't. If you don't, then you 
have to take responsibility for the self-consistency of your own repo 
and that's the primary consideration. Fortunately, in many cases it 
should be possible to achieve that consistency whilst also making 
sharing/transition with other repos possible.

However I think your question is more about people rather than packages. 
Should we be open and encourage the *people* running existing repos to 
get involved? Sure! Should we make that as easy to do as possible? Yes! 
Should be encourage the pooling of efforts with the goal of making the 
best enterprise OS with the most comprehensive and reliable add-on 
packages? Yes! However, every repo has its own policies (e.g. on 
stability, updates etc.). There isn't "one size fits all".  So we can 
never have perfect harmony from a technical perspective, because what's 
right for one repo might not be right for another.

>  * Will it try to work together with these repos? If yes, in what
>    concrete way?

Personally I think this should be mostly done at a "grassroots", i.e. 
per-package level. If I'm maintaining package XYZ and that package (or 
dependents) also exists in another repo, then it would obviously be a 
good idea for me to try to talk to the person maintaining it in the 
other repo and see if we can share resources (which might take many 
forms from swapping spec files or patches, to both contributors agreeing 
to focus on a single repo, whichever it is). Similarly, if the two 
people are going to be maintaining packages that are related then it 
would make sense to try to maintain certain types of compatibility, for 
users that choose to use both repos. However, I don't think we can 
legislate for or enforce this at a high level.

>  * Does EPEL consider itself at the same level as these repos, or does
>    it place itself higher, pushing any compatibility issues to the
>    workload of these repos?

I think each *self-consistent* repo is what it is. It's a repository of 
stuff. If it's self consistent, then compatibility outside of that repo 
with other repos is up to the end user to assess. Of course, it is 
*desirable* to "play nice" with other repos, because we all care about 
making things easy for users, and broadly we're all trying to achieve 
the same things so duplication of effort is wasteful. However, the 
self-consistency of a particular repo has got to be the primary 
consideration, no matter whether that repo is EPEL or A-N-Other Repo.

So in that sense, I believe that *all* repos which are self-consistent 
place themselves "higher" than other repos, within the scope of their 
own activities. That's natural. Speaking from a personal perspective, 
like Michael Stahnke, I maintain a couple of private repos with a 
mixture of custom packages and rebuilds from other repos. Some of those 
are new packages that aren't in the base OS, and some over-ride base OS 
packages, in which case I do the appropriate versioning to make sure my 
custom packages take priority. Now, I don't much enjoy fighting a 
one-person battle to do all this stuff, but it's necessary in terms of 
QA. So personally I welcome the chance to put that effort into a more 
open and collaborative project like EPEL which has documented 
procedures, standards etc. and many people working towards the same 
goal, and I will most likely (of choice) make my private repos 
subordinate to EPEL. However, that's my choice and I don't expect all 
other repo maintainers to necessarily do the same thing.


In summary, whilst I think you're trying to reduce this to a simple 
black/white issue (to co-operate or not with other repos), I don't think 
that it's possible to do that. In particular, I see the need to 
distinguish between other repos and the people running other repos. 
Would I like your personal experience and skills contributing to EPEL? 
Yes. Do I think that EPEL's policies should be affected by existing 
packages in ATrpms? Maybe, BUT only where that is consistent with the 
goals of EPEL and the opinions of other EPEL contributors. If there is a 
conflict between what other EPEL contributors want and ATrpms, then 
that's unfortunate and we should try to avoid it, but at the end of the 
day the self-consistency and maintainability of EPEL is key and you 
shouldn't take it as a personal insult. Sometimes there are times where 
even intelligent, skilled people don't agree. In that case, as a 
self-consistent repo, EPEL (like all other repos) will need to make a 
consensus policy, and contributors should all accept and follow that 
policy, even if they don't agree with it. I know I'm prepared to do 
that, though I acknowledge that that's easier when I'm only supporting a 
private population of users.

Tim