Hallo,
I'm sorry to post in English, I can understand a bit of German, but sadly
I cannot express myself in German very well. My English is somewhat
better, although I would have prefered to do this in Dutch.
I just discovered the 'Fragen zu Synaptic' thread and feel I deserve the
right to answer Michael's new FUD. (And some of the FUD I've seen on the
official Fedora channels in the past months).
I don't mind Michael recruting people to help out the fedora.us project,
the more people helping out, the better. What I do mind is that he has to
trash other projects (3rd party repos) in doing so.
When Michael says my RPM collection is a work of only one person, he is
wrong. The packages I provide are put together by 4 people currently and I
guess around 200 people contribute in one way or another. The other 3rd
party packagers help out too, just like the fedora.us community is
working. (Actually, we're working to open it up more and automate the
process more to make volunteers much more productive.)
What Michael means is that 1 person is doing the actual packaging/signing.
This is more a matter of trust than it is a matter of control. I'm sure
the fedora.us packages aren't signed by everyone involved in packaging,
right?
I wouldn't be able to provide about 8000 packages for 9 different
platforms if it wasn't for the people that test and provide feedback and
the people and tools that help out in the process.
Unfortunately, because of the repeated FUD about the 3rd party
repositories, some news articles took over the same message spreading the
FUD even further, which is obviously harming these 3rd party projects.
It's nice we've been mentioned in almost all the Fedora related articles,
although I don't think the negative connotation often made is
well-deserved or honest.
Here are some facts that I haven't seen mentioned in these FUD threads:
+ We're providing packages for repositories that are not supported by
fedora.us. Red Hat Linux, Red Hat Enterprise Linux, Yellow Dog Linux
and for the x86_64 architecture.
+ We're working together with other Red Hat derivatives and help out
these communities. EL3 derivatives, the cAos project, the BLAG
project. So the community around these packages is larger than just
Fedora.
Both of these points are a clear distinction between my repository and the
fedora.us goals.
+ fedora.us is (and has been) forking packages from 3rd party
repositories (I don't mind, although I'd like to be informed of
improvements when they do). Obviously our packages improve too because
of work by fedora.us, although this cross-breeding could be improved a
lot.
+ fedora.us likes to stress that you cannot use other repositories with
theirs. They say it isn't possible. They are right, it isn't possible
because they don't want too. It's a protectionist measure from the
days that they had few packages and needed resources. It is in
fact possible to make all repositories compatible by investing in
communication and working together.
+ Michael likes to stress that we cannot possibly have quality packages
because we have that many packages compared to fedora.us. What he
fails to mention is that fedora.us is fairly young compared to
other repositories and during the inception months and the many
arguments later, the other repositories grew faster. fedora.us is just
catching up.
+ Some packages I provide are a work in progress and are provided
because people may find it useful nevertheless. It's better to provide
something that can be improved than provide nothing at all in these
cases. Often when they are available, people provide feedback which
wouldn't be there if they weren't available.
I would like to ask Michael and others to talk about fedora.us's merits
without FUDing other projects.
If Michael, Warren or anyone else happens to find something that can be
improved in my packages or wrt. compatibility I would appreciate if you
Cc: me so that I don't have to find out in the archives or via my
referer-log.
Kind regards,
-- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ --
[Any errors in spelling, tact or fact are transmission errors]
