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

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



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


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