Ainsi parlait Denis HAVLIK :
> + directory for 9.0 on mirrors shows they are actually many packages
> + there that are totally new: see enclosed list.
>
> RPM-voting is an attempt to move from the model where
> everyone contributes packages he/she likes without thinking about others
> to a model where users ask for something, and packagers do the packaging
> because someone else needs it. Of course, nothing stops the "volunteers"
> from producing packages they simply like to package too...
I don't think contributers act only for their own. Many contributers,
including myself, often commit packages on behalf of other people. What is
true however is we don't have a formal way to express a desire for a certain
package, except a mail on cooker list, nor do contributers have access on
incoming directory of ftp.linux-mandrake.com, maing uploaded packages only
accessible for Lenny.
> In adition to this "customer-oriented packaging", rpm-voting also offers a
> simple mechanism for quality control, and works basically on its own with
> no need for constant supervising.
Constant automated supervising, restricted commiting access and strict
packaging policy provides higher QA ensurance IMHO.
> In short, Clubs RPM-voting is clearly superior to current "contributions"
> from users point of view, and I hope that everyone will use it in the
> future - both for "stable" releases, and for cooker.
My point is not so much about "how" new packages are elected, neither "who"
creates them, but "where". In current situation, if someone want to package
something for mdk, either for its own needs or because someone else asked
him, he has to dig in cooker _and_ in club (BTW, is there a spec CVS
repository for club ?) to find if the work has already been done.
So i don't disagree with the voting systement, but with the content overlap.
Juste preventing new package introduction at club level would solve this
issue, and forwarding any request to contributers would solve the issue.
--
If a program actually fits in memory and has enough disk space, it is
guaranteed to crash.
-- Murphy's Computer Laws n�5
