Fedora Extras is extra
Dag Wieers
dag at wieers.com
Wed Dec 1 01:47:14 UTC 2004
On Tue, 30 Nov 2004, Jeff Spaleta wrote:
> On Wed, 1 Dec 2004 01:53:30 +0100 (CET), Dag Wieers <dag at wieers.com> wrote:
> > Why don't you start lowering the manpower by automating stuff and allow
> > people to play along.
>
> I'm pretty sure thats the sort of thing Red Hat is internally working
> on as part of lauching Fedora Extras. No one is going to argue with
> you that fedora.us's infrastructure has been lacking. Its a catch-22
> really. If Red Hat had not chosen to merge fedora.us into an official
> Fedora Extras I think more effort would have been made to extend
> fedora.us's infrastructure. But because Red Hat has been working to
> prepare a new infrastructure for Extras there has been considerable
> debate about the usefulness of building up fedora.us's infrastructure
> in the meantime just to scrap it. Hindsight is 20/20... i doubt few
> people inside Red Hat or inside fedora.us leadership thought it would
> take as long as it has to get Red Hat's internal build system ready
> for the merger. In fact... someone has promised me to eat a shoe on
> national television if i can find a station willing to broadcast it..
> because Extras was not ready in time for fc3 release. C'mon... whose
> going to willingly promise me to eat their shoe unless they seriously
> thought everything would be ready in time.
Jeff, let me simply add that I don't read these long paragraphs without
any structure. But that's probably me.
> > The day I do that, the QA queue of fedora.us will be 4x as big as it is
> > now and it will take a long time for these packages to even hit the
> > repository (if ever).
>
> I will fully submit to you that the QA process as originally concieved
> is not the the long term solution.
All fine and well, but I can't add my stuff today. That's what I said.
(everything else you said was again hard to read or follow)
> > I wouldn't be able to update or add new packages because of the overhead
> > that is demanded of me by the policies and procedures that currently lack
> > any automation or infrastructure.
>
> Again... I believe this is exactly the things Red Hat is aiming to
> solve with its infrastructure. And because Red Hat is working on it
> internally..
Fine, I don't mind. Call me when it's there and there are no technical or
other limiting factors. I don't want to enforce my own processes or
procedures and I'm available to discuss them. But if the same work takes
much longer in overhead (and unautomated procedures) and requires more
time of me, I don't think it should be applied to other volunteers as
well. That would be wasting people's time, wouldn't it ?
> > There is a reason why there still aren't any FC3 packages. I don't want to
> > pressure Red Hat and I think this thread is not worth everyone's time
> > spend. But don't give the impression that I'm not willing to cooperate or
> > that it is possible to add packages today, because it simply is NOT.
>
> I know its not. But i will be frank with you. I am under the distinct
> impression... that your other pressures to keep packages trees for
> older rhl and rhel releases greatly impacts how far you are willing to
> bend to be able to contribute to an official Fedora Extras tree when
> it does open up. There is no malice in my statement. I fully
> understand that as a 3rd party repository maintainer you have your own
> established userbase to consider. But I'm not sure how far Red Hat's
> infrastructure and fedora extras policy will be able to accomedate the
> other constraints you impose on yourself by supporting all those other
> trees with your packages.
Actually, I bet you have little idea how it works. But you're right, I'm
not considering duplicating _my_ effort if Fedora Extras does no consider
allowing RHEL2.1 or RHEL3 tags.
If it means forking, the overhead is forced on me, where today there isn't
any overhead. But I do believe you have little idea how my stuff
technically works now, so I'm sure you're overestimating the time spend to
provide backward compatibility.
It's less than 5%, if it does not build on older stuff and it requires
replacing core stuff, it's no longer supported for an older distribution.
Simple as that. Most of the backward compatibility grows in time, if
something used to build and does not longer, a quick check will reveal
whether it's fixable or not.
BTW to build my packages, the only thing required is to add 1 simple
define to your build process. I'm not demanding fedora.us starts building
for everything I'm building. Hell no.
> > First work on the infrastructure before you add voluntary manpower,
> > otherwise you're effectively wasting manpower and potentially ruining a
> > community project. It currently does not scale, tools are missing.
>
> Tools are missing... Red Hat has internal effort to work on this.
That's fine. Call me when it's there. Don't talk about the future as if it
is present. I'm sure my userbase would complain anyway if I waited.
> > Look, we've effectively zero'd all duplication effort by simplying sharing
> > and merging our SPEC files and SPEC development. 4 repositories now are no
> > longer developing their own stuff.
>
> thats 4... out of what.... 3000. I refuse to limit discussion to the
> big repos. there are many many smaller repos out there that deserve to
> be included in any general discussion of costs and duplication. And i
> will argue that whatever gains you get from sharing common spec
> files... is amplified by sharing a common build system competely. And
> the idea of "Fedora Collections" is a future path that demands
> cetralized package building... as the basis for media set generation.
Actually Jeff, there are more repositories. 3000 is a little exagerated
and I don't want to belittle the smaller repositories, in fact I would
invite them to join RPMforge, when they feel they're ready or when we're
ready to invite them.
BTW Those 4 repositories are spending a large part of the overall effort
in Red Hat contrib packaging. A modest guess would be +40%, so if we're
talking about real effort in total, I think it's a considerable gain.
The advantage is that their stuff will be build for RHEL2.1, RH7.3, RH9,
RHEL3, FC1, FC2 and FC3. For several architectures, i386, x86_64, alpha,
ppc, sparc. And we may add support for other distributions like SuSE or
Conectiva with little overhead and even less duplication effort than
you've been talking about so noisely.
So yes, it's not limited to Fedora. And I'd rather not exclude myself from
Fedora Extras if it's not necessary. I think it's a mutual advantage to
work together, at least if the burden is not on me. (Evenly it doesn't
have to be on Fedora Extras either, as my stuff is already Fedora
compatible in essence)
Remember that I'm not necessarily duplicating effort here, in a lot of
cases fedora.us has been duplicating effort since my stuff was already
openly available and they've chosen to ignore that. The interfacing
simply was never there.
As you can see this has nothing to do with emotions or egos. I'm sure some
people want you to believe that and I'm sure that if you believe that, you
can see the signs everywhere. Especially in my signature !
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[All I want is a kind word, a warm bed and unlimited power.]
More information about the fedora-list
mailing list