On Fri, 5 Nov 2004 18:46:19 +0100 (CET), Dag Wieers wrote:
> > There are a very few people (or maybe it's just one) who don't realize
> > that I'm just a contributor. I'm not in charge of the policies and
> > objectives. I'm not a fedora.us spokesman either. Gah! It's insane to
> > think that, when I never ever claimed to be a spokesman. Fedora.us
> > provides a system which allows community commitment, where I, as a member
> > of the community, can contribute. Other contributors have noticed the
> > possibility, too. On the contrary, when fedora.us was started, and even
> > many months later, no other packaging project was ready to accept
> > community commitment beyond private mails or mailing-lists.
>
> That's not really correct, Michael. It may be your believe, but the fact
> that at the start most of the 3rd party packagers were involved in
> fedora.us is a clear indication that we believed in a single merged
> repository in the long run.
Some random excerpts and quotes from the old list, roughly in
chronological order:
Nov 2002 : Axel Thimm wants packages to be vendor independent, while
Panu Matilainen says that would be beyond his time to test on any other
distribution than RH
Nov 20 2002 (Axel Thimm) : Of course only if Matthias is willing to
expand his one-man-efford to allow inclusion of trusted third party
effords, but this is how he described rpmforge.net. The next step is to
have some mechanism for those built packages to enter freshrpms.net.
Feb 5 2003 : Axel Thimm (AT) suggests Epoch bumps for alpha|beta|rc
in %version
Mar 1 2003 : controversies about package naming guidelines
AT : That is why one needs to solve the coordination problem of
multiple repositories before merging them.
Warren Togami (WT) : The only long term maintainable solution for
Fedora is to simply have MORE packages than all other repositories.
It was the intent of this project to hopefully unify the various
independent packagers and forever put an end to incompatibility.
AT : The second step is to build upon the established
situation. freshrpms.net is the standard repository (besides Red Hat),
and that is a fact. Anything else that going in harmony with freshrpms
is bad. If there are reasons to dislike some of Matthias practices,
one should invest time in arguing and coming to an agreement, and not
in a takeover. Matthias and Red Hat _are_ the vendors ... ;)
Mar 6 2003 : Warren Togami wants Matthias Saou as release manager
Matthias Saou says he doesn't know whether he's suited for that or not.
He may be too picky.
March 2003 : Seemingly endless controversies about package versioning
and explicit Epochs, package signing,
Mar 7 2003 : Axel Thimm sums up his goals and forsees flames.
Message-ID: <20030307101746.GC5882@xxxxxxxxxxxxxxx>
c) Coming to agreements about general repository guidelines (cerating
specifications etc).
d) Consolidating the repositories into one (involving creating the
neccessary infratstructure).
that is also the coarse view on milestones, I would set. I know that
people want to start at d) and want to get the project rolling at full
speed, I'd also like to see the perfect specifications and
systems. But the recent discussions about versioning, security
infrastructures etc. show that the project should invest more in its
planning phase, before getting in the executive one.
IMHO d) depends on Matthias willing to bring his rpms over (better
said willing to host the rest of ours - would even solve the name and
domain problem ;). I don't forsee that he will do currently something
like that, but I never give up hope! ;)
Anyway copying freshrpms.net has already been stated as a bad idea,
therefore at least there an interrepository arrangement has to be
made. Other smaller repositories (O.K., so I am also thinking about
mine ;) would also like to be considered.
Therefore I suggest to have a stronger focus on specifications about
inter-repository coordination. Let us coordinate the repositories to
such an extend, that one could indeed copy them all together into one.
That would involve a common agreement on versioning and overlapping
rpms. I hope that this way more repository owners will be willing
contribute, as it merely includes a common sense ;). Having the project
rolling in this mode for some time will enable the packagers to
establish and learn methods for common "rpm fighting", and give a good
taste on fedora. Finally the common repository will be only a matter of
infrastructure. :=)
I know I will be flamed, try to be gentle on me. ;)
Mar 11 2003 : Axel and Warren clash, Warren sees large delays in the
specification process.
Mar 21 2003 : Dag Wieers joins, active in kernel module packages discussions
Apr 5 2003 : Epoch controversy continued... (Matthias Saou)
"Oh well, seems like I'm the ony one arguing _against_ introducing
mandatory epoch fields in all packages... :-("
Apr 19 2003 : AT
Currently fedora is creating the nightmare you mention. People
_expect_ different repositories to be mixable, apt and yum provide
ways to have different sources, and then you create something
incompatible to any other repository out there?
If freshrpms.net is your 'source of inspiration' why do you stab at it
(and all the other repositories)? Instead of putting so much energy in
replacing or swallowing freshrpms, you could try to extend
it. Matthias has signaled to accept patches, if his builds can be
improved, and he seems to do so. What was so wrong with freshrpms?
[...]
When I joined fedora I was excited about having a project to create
inter-repository coordination and compatibilty rules.
Apr 19 2003 : Dag explains why he replaces packages in freshrpms
Well, I decided to 'replace' some of freshrpms packages because I
didn't have control over the dependencies. (Especially for the
audio/video packages, this was sometimes a pain) and I couldn't build
packages against freshrpms when freshrpms wasn't building against mine
;))
Summary: my repository is self-contained but still compatible with
freshrpms.
Apr 19 2003 : Dag continues with inter-repository library standard
proposals
May 2003 : Matthias Saou comments on normal discussion,
QA work as fedora.us starts, more and more packages appear
July 2003 : Matthias tries to defend his "single person entity"
Nov 8 2003 : Hostile words from Axel Thimm. Panu Matilainen
points out that Axel misunderstood the goals of fedora.us
Dag Wieers: [...] most 3rd party packagers already had more
packages then Fedora currently.
Whoever may be in search of my first comment on the result of many months
worth of discussion, enter the archives around Nov 2003. Older messages
from me are unrelated.
> The real question is, is there an
> intention now to find some common ground and loose some of the
> duplication efforts or not.
Well, let's hope so. Fedora Extras will give the opportunity to extend the
package set and also base 3rd party repositories upon it. Then those 3rd
party repos no longer need to provide the same libfoo-1.0 that is in
Fedora Extras already. Repositories which find Fedora Core not bleeding
enough and thus upgrade Fedora Core, will remain a different side of the
story.
> You have to know that of course Fedora is a too limited view (I've
> repeated that before on the fedora.us mailinglists too). Our packages work
> for much more than just Fedora and our userbase is therefor much wider
> than only Fedora and only i386.
I don't mind distribution-independent packages if I don't need to QA or
support them. And if the distribution independence doesn't result in
bloated spec files and/or patches, which are more difficult to
proof-read. I hope that using a source code management system for packages
will avoid that, since it allows forking package development for different
distributions. I would not like to spend any time on testing something
for rh80, a distribution which is not even supported by Fedora Legacy
anymore.
> This should also be appealing to Red Hat, since having a wide set of extra
> tools and packages that also work for RHEL will only help in selling Red
> Hat in a lot of environments.
I doubt that extra packages alone increase Red Hat's sales. True, there
are some customers, who appreciate some prebuilt extra packages (I've seen
the messages on taroon-list, too). But increased customer demand would
cause Red Hat to become active and support extra software themselves,
e.g. anti-virus solutions.
> Ok, I thought it was a compliment if I said fedora.us is maturing, but if
> you say it isn't, I'm not going to argue with you. :)
If you did, I would scratch my head and then shake it in disbelief. ;)
--
Fedora Core release 2 (Tettnang) - Linux 2.6.9-1.2_FC2
loadavg: 0.01 0.02 0.00
