[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Fedora Extras is extra
- From: Dag Wieers <dag wieers com>
- To: Jeff Spaleta <jspaleta gmail com>, For users of Fedora Core releases <fedora-list redhat com>
- Subject: Re: Fedora Extras is extra
- Date: Wed, 1 Dec 2004 05:54:43 +0100 (CET)
On Tue, 30 Nov 2004, Jeff Spaleta wrote:
> On Wed, 1 Dec 2004 02:47:14 +0100 (CET), Dag Wieers <dag wieers com> wrote:
> > 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.
> As long as we are clear on where your tight constraints are. Are there
> any other tight constraints that would prevent you from contributing
> to the centralized process you want to air now for the record?
Well, I don't see them as constraints really. Quite the opposite, I'm now
constraint to modify my SPEC files to only work for Fedora, while that
constraint could easily be lifted with just a few agreements of a
standard. A standard that would even benefit cross-fedora rebuilds from
the same SPEC file with little effort.
BTW whatever in my proposed standard is unacceptable I'm willing to drop
as long as the same functionality is there. With some RPM adjustements,
already discussed with JBJ, it could even be incorporated with RPM.
And, Jef, I'm convinced that if this is not decided now, they will have a
similar feature in a couple of years anyway. Because it's so simple and
saves so much time that it's even strange there hasn't been an accepted
BTW Some Red Hat packages (like sendmail) used to have similar things
included like we adopted, so it's not new and no rocket science either.
It's just a standard way of working and a standard naming policy of
> > 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.
> I make no effort to estimate how much effort you spend inside your own
> build system. I am concerned about how much effort Red Hat has to
> expend to accomedate your external contraints and how far your
> external contraints allow you to bend to work inside what fedora
> process whatever that publicly communicated process is.
Well, that's fine than. I don't want to enforce any policies, I don't
think I'm in a position to make demands anyway. But you asked for my
concerns, I gave them, and that's that. If it is decided that it does not
fit, no problem.
But don't say I'm the one duplicating effort and all that nonsense.
> > 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.
> > 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.
> "When we are ready to invite them"... thats an interesting sentence on
> the heels on your request for me not to talk about the future as if
> its the present. I'm more than willing to play the part of kettle if
> you are willing to play the role of pot.
Yes, that sentence means that we're not inviting everyone right now
because it would not scale and mark the end of the project sooner than
later. I thought we handled that ?
> RPMforge is there to address the needs of a small group of established
> 3rd party repos, it will not scale to accomedate all packagers and all
> repos. I feel RPMforge does more to protect the established brandname
> status of established repositories than it does to provide a community
> framework for future packagers and initatives. I'm not exactly happy
> with the idea of encouraging as Fedora policy a 'community' of
> packagers that will not scale to include individuals who have skill
> but not their own infrastructure for distribution.
No, it's common sense. I admit we don't scale and frankly I don't think
allowing everyone to add things is a very good idea overall. I'm sure
Fedora Extras will have the same policy. Mark my words, everyone can help
out, but not everyone will have commit access or be able to build
packages. Common sense, Jef.
If you argue we should enter into the same mess (let's call it that
because my English does not have a softer word) as fedora.us, which is
also NOT scalable, we are not going to do that.
I rather explain to people why at this point we lack the tools and
infrastructure to scale, they're free to help build those tools and
infrastructure and if they've proven that they can work with us with
limited overhead no problem. Existing packagers can do that, that scales.
I'm sure you understand all that very well. It's sad that we can't allow
everyone to be involved in the actual building, but they can do a whole
lot providing feedback, bugfixes, improvements and even contributing SPEC
files. And if the time's right they can join if they're committed.
But that's reality, no beating around the bush here.
> > 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.
> No one argues that right now, today, 3rd party repositories are not
> playing a significant role.
If you say so :) You'd be surprised.
> > 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.
> If providing cross distribution packages and EOL'd distribution
> packages is the goal you seek.. then by all means... use your
> resources as you see fit. But whether or not these goals are
> considered compatible with Fedora project policy and long term plans
> remains to be seen. I believe tying package building as closely to
> each distribution's own process as possible is a better use of
> resources and provides better integration with each distribution.
Again, I never said that Fedora Extras view should be to do the same thing
as I am doing wrt building for multiple distributions. Where do you get
that from ?
But they should allow the extra information inside the SPEC file so that I
do not have to fork my stuff to have a special edition for fedora.us.
If not, they are limiting me (and the contributed SPEC files), not the
other way around. And in that case it probably has to do with control and
power instead of community and sharing.
To me it's clear you don't have a clue what I'm talking about technically
and I think it makes no sense to discuss this any further. We're not
> Personally from your statements, I get the feeling that the cost of
> any extra overhead to have your packages appear in the Fedora build
> system will be too much for you to be willing to contribute to a
> centralized process that lays the ground work for an expanded and more
> flexible Fedora project.
How can you know ? We don't know the Fedora Extras process and what we
discussed until now was about the terminated fedora.us project.
Again if you would have any clue to what is necessary to build our SPEC
files in another build system, you wouldn't be exagerating the effort here
and now. You have the same flexibility to fine-tune to a distribution and
the cross distribution stuff is more about creating communities around
individual packages between distributions, than about building exactly the
same package on all distribution. If that's what you think, broaden the
> If that is the case, I will simply leave you
> with good luck to you and your efforts. But please, if you do decide
> not to contribute to Fedora Extras lets make a clean break of it. I'm
> not thrilled about the idea of having this sort of conversation again
> 6 months from now with someone who isn't really invested in trying to
> work within the established framework (even if that framework is
Sorry, but I did not start this thread and I'm only responding to some of
the things that popped up and that either were wrong or misguided. And
most of the confusion that people have comes from the fedora.us document
in the first place and the lack of information about Fedora Extras.
Implying that I'm not willing to work together (what you've done
repeatedly now) is not really nice though.
-- dag wieers, dag wieers com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
[Date Prev][Date Next] [Thread Prev][Thread Next]