Quoting Andreas Schneider <[EMAIL PROTECTED]>:
Pau Garcia i Quiles wrote:
The problem with a restricted-access repository is we would
probably have the same issues we have now: you need to ask for
access, which would not be granted to you until you are
"well-known" and/or you've got some really interesting
contribution. Not a big improvement, IMHO.
You don't know how git works, don't you? You can send a patch or let
the maintainer pull from YOUR repository. It's much easier than svn or
cvs.
I know how git works (and mercurial, too, by the way) but I don't see
people setting up their own git repositories just for other people to
pull two FindWhaterEver.cmake.
Even if people really interested in sharing their finders would up git
repositories, we still have the search and quality problems
* Search: while searching for a FindXXXX.cmake, you would visit a lot
of repositories one by one
* Quality: as you don't know how many people downloaded that
particular finder, you've got no way to know if that particular
FindXXXX.cmake is good or bad because you would not know how many
people downloaded it.
The search problem would be easily solved by a CMakeForge. What it
uses to store the finders is not important, it could perfectly be git
instead of just plain files as SourceForge, RubyForge, etc do.
The quality problem is trickier. I know "number of downloads" is not
the best quality measure but it's better than nothing. Ideally,
finders should be rated by people using them. In fact, CMake could try
to do the rating itself, using an approach similar to the
popularity-contest package in Debian: take a SHA1 sum of every
unofficial finder and submit it to cmake.org, and show how many people
are using it (this should be optional, of course). Maybe show the "top
20" unofficial finders in the front package of cmakeforge.cmake.org.
I'd like to propose a huge change: let's have a SourceForge-like
site (what about CMakeForge at http://cmakeforge.cmake.org ? )
Then we have the same as we have now. Several hundered projects with
the same FindXXX.cmake modules and each project has its own copy.
The problem with having a single centralized repository is triage. Who
is going to decide which finder for a particular library is the
"official unofficial" finder? After seeing the infinite thread about
FindBoost.cmake I'm not sure that could be managed in a proper way for
a large number of finders.
The easy way to sort that problem is let it solve by itself: if there
are 5 FindBoost.cmake in CMakeForge, I'd probably go for the
most-downloaded one (or the most-used one, if cmake-popularity-contest
is implemented).
Talking about Boost, now that Boost is moving to CMake, has anyone
asked them to "bless" FindBoost.cmake? (AFAIK they don't provide one
yet)
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
