Fedora Extras is extra

[Dag Wieers]

On Tue, 30 Nov 2004, Jeff Spaleta wrote:

> On Wed, 1 Dec 2004 02:47:14 +0100 (CET), Dag Wieers <dag at 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 
standard already.

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 
macros.


> > 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 
getting anywhere.


> 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 
view.


> 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
> fubared..

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 at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]