| 1 |
Since we currently have language herds for other languages such as Ada, |
| 2 |
Perl, and Java, I don't think C++ should be any different. There are |
| 3 |
currently many packages in the tree that are C++ libraries or utilities |
| 4 |
that are no-herd and are actively maintained, and there are probably |
| 5 |
some that have just been sitting around rotting. With the creation of a |
| 6 |
C++ herd, there would be a team that could support these packages, |
| 7 |
instead of a single maintainer, if the package has one. Below is a list |
| 8 |
of all of the packages that I believe would qualify as falling under |
| 9 |
this herd. If you see your name in the following list, I'd especially |
| 10 |
like to hear from you. Names with a '?' next to them are packages that |
| 11 |
had no metadata and I guessed from the changelog who the maintainer is. |
| 12 |
I would also like to see many of them, if not all, moved to the dev-cpp |
| 13 |
category: |
| 14 |
|
| 15 |
dev-cpp/commoncpp2 (no-herd, arj) |
| 16 |
dev-cpp/gccxml (no-herd, g2boojum) |
| 17 |
dev-cpp/libibinio (no-herd, spock) |
| 18 |
dev-cpp/poslib (no-herd, matsuu) |
| 19 |
dev-cpp/rudiments (no-herd, matsuu) |
| 20 |
dev-db/libodbc++ (no-herd, robbat2) |
| 21 |
dev-libs/STLport (no-herd, vapier?) |
| 22 |
dev-libs/asyncresolv (no-herd, jhhudso?) |
| 23 |
dev-libs/blitz (no-herd, dragonheart) |
| 24 |
dev-libs/boost (no-herd, morfic) |
| 25 |
dev-libs/cgicc (no-herd, ka0ttic) |
| 26 |
dev-libs/commonc++ (duplicate of dev-cpp/commoncpp2 as far as I |
| 27 |
can tell, unmaintained?) |
| 28 |
dev-libs/darts (no-herd, unmaintained?) |
| 29 |
dev-libs/dvacm4 (no-herd, pvdabeel?) |
| 30 |
dev-libs/dvcgi (no-herd, ka0ttic) |
| 31 |
dev-libs/dvutil (no-herd, ka0ttic) |
| 32 |
dev-libs/fampp2 (no-herd, vapier) |
| 33 |
dev-libs/ferrisloki (no-herd, vapier) |
| 34 |
dev-libs/ibpp (no-herd, sekretarz) |
| 35 |
dev-libs/korelib (no-herd, george?) |
| 36 |
dev-libs/libcoyotl (no-herd, aliz) |
| 37 |
dev-libs/libevocosm (no-herd, aliz) |
| 38 |
dev-libs/libferrisstreams (no-herd, vapier) |
| 39 |
dev-libs/log4cpp (no-herd, george?) |
| 40 |
dev-libs/log4cxx (no-herd, ka0ttic) |
| 41 |
dev-libs/luabind (no-herd, rphillips) |
| 42 |
dev-libs/ntl (no-herd, george?) |
| 43 |
dev-libs/pcre++ (no-herd, eradicator) |
| 44 |
dev-libs/ptypes (no-herd, dragonheart? george?) |
| 45 |
dev-libs/quantlib (no-herd, vanquirius) |
| 46 |
dev-libs/rlog (no-herd, vanquirius) |
| 47 |
dev-libs/socketstream (no-herd, george? dragonheart?) |
| 48 |
dev-libs/sucs (no-herd, ka0ttic) |
| 49 |
dev-libs/swl (no-herd, trapni upstream dead? The site |
| 50 |
appears to be dead) |
| 51 |
dev-libs/wefts (no-herd, flameeyes) |
| 52 |
dev-libs/xerces-c (no-herd, halcy0n) |
| 53 |
dev-libs/xmlwrapp (no-herd, ka0ttic) |
| 54 |
dev-libs/yaz++ (no-herd, robbat2) |
| 55 |
dev-util/leaktracer (no-herd, svyatogor?) |
| 56 |
net-libs/socket++ (no-herd, ka0ttic) |
| 57 |
|
| 58 |
Possible candidates (most of these are for C and C++): |
| 59 |
dev-libs/nana (no-herd, pyrania?) |
| 60 |
dev-libs/xmlrpc-c (no-herd, jhhudso) |
| 61 |
dev-libs/xxl (no-herd, ka0ttic) |
| 62 |
dev-util/astyle (no-herd, karltk) |
| 63 |
dev-util/bcpp (no-herd, chriswhite?) |
| 64 |
dev-util/cccc (no-herd, dragonheart?) |
| 65 |
dev-util/ccmalloc (no-herd, dholm) |
| 66 |
dev-util/cdecl (no-herd, phosphan) |
| 67 |
dev-util/cweb (no-herd, no one) |
| 68 |
dev-util/flawfinder (no-herd, aliz?) |
| 69 |
dev-util/rats (no-herd, robbat2) |
| 70 |
|
| 71 |
Currently under another herd, but seems to make more sense here: |
| 72 |
|
| 73 |
dev-cpp/libxmlpp (gnome-mm, ka0ttic) |
| 74 |
dev-cpp/sptk (desktop-misc, iluxa?) |
| 75 |
dev-libs/libsigc++ (gnome-mm, ka0ttic) |
| 76 |
dev-libs/libsigcx (gnome-mm, ka0ttic) |
| 77 |
dev-libs/mxmlplus (text-markup, usata) |
| 78 |
dev-libs/xplc (net-dialup, mrness) |
| 79 |
dev-util/cppunit (lang-misc, george?) |
| 80 |
dev-util/qtunit (kde, centic?) |
| 81 |
net-libs/wvstreams (net-dialup, mrness?) |
| 82 |
|
| 83 |
|
| 84 |
I would like all of the current maintainers of these packages to keep |
| 85 |
maintaining them, and they wouldn't be required to join the cpp team, |
| 86 |
but there are a few people that seem to maintain quite a few C++ |
| 87 |
libraries that might be interested in joining. |
| 88 |
|
| 89 |
If there is not a very good reason against the creation of this herd, I |
| 90 |
would like to do so in the coming week. As for the name, cpp may be a |
| 91 |
little misleading, any better suggestions? In the list above, I have |
| 92 |
libraries for C++, as well as utilities. |
| 93 |
|
| 94 |
Thanks, |
| 95 |
|
| 96 |
Mark |
Archives