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