[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Extras is extra



On Tue, 30 Nov 2004, Jeff Spaleta wrote:

> On Wed, 1 Dec 2004 01:53:30 +0100 (CET), Dag Wieers <dag 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 wieers com,  http://dag.wieers.com/  --
[All I want is a kind word, a warm bed and unlimited power.]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]