[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Relationship to existing 3rd party repos/CentOS/SL?
- From: Tim Jackson <lists timj co uk>
- To: epel-devel-list redhat com
- Subject: Re: Relationship to existing 3rd party repos/CentOS/SL?
- Date: Thu, 19 Apr 2007 12:19:26 +0100
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
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.
[Date Prev][Date Next] [Thread Prev][Thread Next]