On Sat, 26 May 2007, Thorsten Leemhuis wrote:
will leave EPEL if we don't get them. I'd even go a step
further and say now that I'll leave EPEL if we don't find a
peaceful way of co-existence with Dag and Axel and CentOS.
Maybe we can even get back to the drawing boards and find a
way to cooperate.
Please don't threaten so, and please don't leave. -- As I see
it, you have finally stopped fighting with Dag and Axel, and
are more clearly thinking about the real world support
implications of some so-called 'political' infighting within
EPEL and Fedora. I appreciate your work.
There is lots of history and and plenty of choices in all of
our pasts -- some packagers have chosen to assent to the RHEL
License, others have not or cannot; some have chosen to
consent to the Fedora CLA, others have not, or cannot. Some
have availablity, and spare time to 'pounce on email' to
conduct 'conversations' in near real time, others do not. Some
use IRC, some do not.
I suspect that an amicable 'federation' is about all that one
can achieve; in light of the Epoch wars, the repotags battles,
and the EPEL tone to date, things are not promising, and at
the end of the day, in FOSS, one can choose to fork. Not all
differences among branches of a fork can be merged.
My antecedents are readily knowable: I have been an
independent packager since before there was a fedora.us; I
co-founded cAos, and when the CentOS sub-project needed to
seperate to address a certain trade mark threat and so forth,
I was there. I publish GPLd code, and when GPL v 3 issues, we
(my coding partner and I) have already concluded we will
re-license and advertise our support for it at once.
Spot and I have been in the versioning wars a long time; I
strongly disagree with his current conclusions on repotags;
some strongly disagreed with Red Hat on gcc-2.96 - - I find
this in my archive from spot dated 06 Feb 2003; I heartily
agreed with RH then, and in his build in Aurora and sparc
space.
Because it isn't Perl 5.6.1sparc, its Perl 5.6.1. You're
opening a big old can of worms when you start modifing
someone else's release number (*cough*2.96RH*cough*).
I _think_ he meant Version as there was no intervening dash.
The fight moves from Version to Release, for repotag to live
at at the RHS of, (some time ago I discussed the matter in
private IRC directly with him, and we simply disagree) and as
a matter to appear in the 'as built' external binary RPM name,
or even in a NEVR to disambiguate, I _like_ repotags. But I
cannot sign the CLA, and so cannot vote on the matter. Yes, I
know, and concur that rpm -qi can do so, and so can signing
keys (congratualtions, Panu on your new position) and more --
but in doing real world support, NEVR is about all one gets,
as I see and do it.
From the May 23 IRC transcript meeting -- I have done minor
snips from the IRC log, trying to get a thread which fairly
presents what I see in reading the transcript which crossed
this list. I _like_ spot [he has a standing dinner invitation
whenever he is in my city], and I am a Red Hat shareholder,
and I strongly respect the FSF Four Freedoms. These three
cannot be reconciled to profit AND freedom maximize -- I live
with the ambiguity.
00:34 < f13> | I'm just failing to see the value in "working
with" a set of repos that we can't mention, we can't guide users to, we
can't preconfigure user's systems for, we can't expect users to
magically discover that there is another repo they have to manually add
to get access to potentially useful software, that we could just put in
repos that we _can_ guide users to.
00:35 < f13> | unless "working with" involves helping htem get
all software that _can_ be published through EPEL into EPEL.
later
00:50 < f13> | as that would essentially be giving away RHEL
binaries for free and silly RHEL management doens't like that idea one bit.
00:51 * | mmcgrath notes we should have just used the
centos binaries...
00:51 < f13> | nor do they like the alternative of
using CentOS binaries.
later
00:51 < mmcgrath> | f13: Do 'they' like epel at all?
00:51 < mmcgrath> | :)
00:51 < f13> | mmcgrath: oh sure! they LOVE epel....
00:52 < mbonnet> | mmcgrath: "They" are all for EPEL
00:52 < f13> | (it gives them a place to say "no, we don't want
to accept this new package in RHEL, go play in EPEL"
later
00:53 < smooge> | well your build options look to be : RHEL but
locked down and hidden, CentOS but not admitting it, or SciLinux but not
admitting it
00:54 < stahnma> | OH, there's unbreakable linux too
I think the main problem which EPEL has not faced, is that
RHEL management (and control decisions in Fedora with the
demise of the independent Fedora Community Foundation
commitment ["one cannot serve two masters"]) are reportable to
Red Hat management ("RHT"), and at the end of the day, I
expect (wearing my shareholder's hat) RHT (its stock ticker
symbol) to properly manage its assets, its brands, and its
property to maximize shareholder value. The success in
recruiting legions of Fedora folk says they are doing well;
that I personally choose not to accept the License offered
does not diminish my respect for their management of RHEL and
Fedora.
EPEL is another (non-Fedora) part of RHT's 'One Ring to Rule
Them All', to my way of thinking -- A buildsystem building
with restricted availability binaries, and a CLA are not for
me, but may be for others. Until its buildsystem can be
reconstructed using binaries from freely rebuildable sources,
and until some FUD ceases, EPEL is not for me.
I veered away (forked, if one prefers) a long time ago, to the
initial fedora.us, then cAos, and am perfectly happy with it
and CentOS. I still file bugs on the Red Hat Bugzilla as no
CLA applies. I filed one earlier today, pro Freedom.
Get over it, and move on. Diversity in packaging and
buildsystems implementations may save us rather than cripple
us.
So, as I said, I'm quite unhappy with the current EPEL state
-- just as Dag, Axel and some others are.
I choose not to be unhappy as I consider it a fool's errand to
seek some 'Grand Unification', and do not make myself unhappy
wishing for things which cannot occur.
For me, CentOS and my SRPM archive (for missing elements which
customers have been provided) yields access to stability
consistent with my views on the Four Freedoms -- I do not see
that adding a EPEL binary archive can ever reduce risk in a
production environment at my clients; cAos adds the latest and
greatest for me if I wish to walk on the wild side -- Fedora
has a CLA entry barrier.
I'd really like to find a way out of this mess.
I wish you luck, but ...
afaics to a big part evolved because mail communication sucks.
No -- email as practiced without proper trimming, and with
snap responses without thought, rather than considered
comment and responses sucks.
IRC is even trickier, and I still get it wrong from time to
time in #centos on freenode and the adjunct channels through
the day. Come lurk for a week, and get the flavor of the
participants.
When Max showed up one day in #centos, I recognized him, and
took him off for a nice pre-FOSDEM IRC meeting with the
important CentOS developers who happened to be around [we are
still waiting for some replies on matters discussed]; This is
nothing new as I know most of the players from years in RPM,
F, and RHEL space and can 'greet them' at the door. dgilmore
was at ClueCon at my invitation last year as I presented on
CentOS, CACert and telephony matters. Earlier in the year, I
sought out and spoke with warren at SCALE. In between, I met
up with seth in real life at OLS. One can only do so many
conventions. ;)
CentOS folks are not hard to find. Others from @redhat, and
in Fedoraspace lurk there as well, and I suspect it is because
of the S/N quality of the channel. CentOS folk are not hard
to find, but is likely that out of courtesy to others there,
discussions may move to a side channel.
A real life meeting maybe could get this mess solved. I'd
actually would like to have someone around that could speak
for CentOS, too.
I believe Lance has stated his intention to be at the event,
and Lance is thoughtful in expression, knows the issues, and
listens well, and will no doubt discuss what he hears back to
the other core CentOS developers; I trust Dag and Axel's
instincts as well, and imagine they will discuss what they
heard being said. I too 'listen', to this list, to IRC, to
promises made and actions taken.
One parting thing to consider -- I think of what are referred
to as 'third-party' packagers and archives, as instead
'Independent' packagers and archives
-- Russ Herrold
herrold(a)centos.org
herrold(a)owlriver.com