Re: [gentoo-dev] [RFC] C++ herd proposal
Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. -- / Georgi Georgiev/ Putt's Law: Technology is dominated by two/ \ [EMAIL PROTECTED]\ types of people: Those who understand what \ / +81(90)2877-8845/ they do not manage. Those who manage what / \ --- \ they do not understand. \ pgpcsS58zjKuP.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Georgi Georgiev wrote: maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. portage isn't supposed to offer eternal functionality status for personal overlays. what if an eclass gets obsoleted and eventually is removed from the tree? the only problem is binary packages screw up. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Tue, 2005-09-20 at 08:54 +0200, Kevin F. Quinn wrote: On 20/9/2005 7:37:19, Georgi Georgiev ([EMAIL PROTECTED]) wrote: maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? That's been discussed a number of times already. The best idea is to leave the categories alone and forget that the category means anything. Or, to throw the ball back in your court, could *you* suggest alternatives that accomplish the following: (quoting [1]:) More precisely, what I'd like to see, in order of preference, is - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed - the net-wireless/gnome-phone-manager that I have in my overlay to work for as long as needed - my net-wireless/gnome-phone-manager binary packages to work without having to be fixpackaged - the location of the ebuilds for net-wireless/gnome-phone-manager to stay in the same physical path on my filesystem end quote I would grade the above features as vital, badly needed, happy to see it done, cosmetic. I.e., even solving only the first one is enough, though if you could get to number two it would be better. Here's another requirement I'd like to add to the list: - when moving stuff around, change history moves too CVS doesn't support this, but subversion does (along with atomic commits, also useful to ensure integrity of the tree during a move). The support for symlinks in subversion may also provide a way to resolve the overlay problem... Technically it does support it if said developer gets Infra to move it server side some nasty side effects, etc, but lots better than our current situation where some bright spark removed most if not all history of stuff that was moved :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] C++ herd proposal
On Tue, Sep 20, 2005 at 10:01:39AM +0300, Alin Nastac wrote: Georgi Georgiev wrote: maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. portage isn't supposed to offer eternal functionality status for personal overlays. Eh? what if an eclass gets obsoleted and eventually is removed from the tree? Pull from viewcvs. I assume you're talking about portage =2.1 capabilities, since you *cannot* remove an eclass from the tree once it's been added currently. the only problem is binary packages screw up. Binpkgs should be running from their own env, they should be stand alone not requiring even a tree. Back on subject... I *really* don't like categories. Single vdb, single repo, single binpkg, it's not horrible. Multiple true, standalone repos, with the occasional binpkg repo used? It makes doing the category move *really* rather hard, since you need to track down exactly which repository and ebuild came from. ~harring pgp81JlK7zAMI.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Schlemmer wrote: | Technically it does support it if said developer gets Infra to move it | server side some nasty side effects, etc, but lots better than our | current situation where some bright spark removed most if not all | history of stuff that was moved :/ Not really any side effects if you do it right. Copy the ,v files (don't just mv them), then cvs rm in the old location. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDMDmaXVaO67S1rtsRApZtAKCefgS2okfjNcpQpBUekthLdj4XhgCguCMQ zFLmx9mPBX+dYwR/YS5WE6M= =BwBQ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 22:24, Mark Loeser wrote: Mike Frysinger wrote: On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote: The reason for me adding that bit is the metadata from dev-cpp: The dev-cpp category contains libraries and utilities relevant to the c++ programming language. Now to me, that means I can find *all* relevant C++ stuff here. If we don't want that to be the case, maybe we should say miscellaneous, but why should something be in dev-libs, as compared with dev-cpp? net-libs, I could understand, and dev-games, as those could be argued to have a direct relation. for generic C++ packages (STLport/boost for example), i can see them being in the dev-cpp category ... but for packages which have specific uses already and arent in 'generic' categories, i dont think they should be moved I agree with this, but I think dev-libs and dev-util are generic categories, and moving these packages from there would help users in finding what they need. I think this is what you are saying atleast :) I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpzqRee7apvu.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? pgpYUgBMZbynY.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? That's been discussed a number of times already. The best idea is to leave the categories alone and forget that the category means anything. Or, to throw the ball back in your court, could *you* suggest alternatives that accomplish the following: (quoting [1]:) More precisely, what I'd like to see, in order of preference, is - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed - the net-wireless/gnome-phone-manager that I have in my overlay to work for as long as needed - my net-wireless/gnome-phone-manager binary packages to work without having to be fixpackaged - the location of the ebuilds for net-wireless/gnome-phone-manager to stay in the same physical path on my filesystem end quote I would grade the above features as vital, badly needed, happy to see it done, cosmetic. I.e., even solving only the first one is enough, though if you could get to number two it would be better. 1: http://groups.google.com/group/linux.gentoo.dev/tree/browse_frm/thread/26b3b93fe16de00c/3ffe93800adbc578?fwc=1#o3ffe93800adbc578 -- /\ Georgi Georgiev /\ Vulcans never bluff. -- Spock, The Doomsday /\ \/[EMAIL PROTECTED]\/ Machine, stardate 4202.1\/ /\ +81(90)2877-8845 /\ /\ pgpChTvi247OB.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 22:14, Mike Frysinger wrote: On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote: Kevin F. Quinn wrote: I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? The reason for me adding that bit is the metadata from dev-cpp: The dev-cpp category contains libraries and utilities relevant to the c++ programming language. Now to me, that means I can find *all* relevant C++ stuff here. If we don't want that to be the case, maybe we should say miscellaneous, but why should something be in dev-libs, as compared with dev-cpp? net-libs, I could understand, and dev-games, as those could be argued to have a direct relation. for generic C++ packages (STLport/boost for example), i can see them being in the dev-cpp category ... but for packages which have specific uses already and arent in 'generic' categories, i dont think they should be moved -mike if I do understand you correctly, I'd even not use dev-cpp as category, instead something that contains the word `platform` or `framework` in it, as STLport/boost/STL(libstdc++-v3,...) and others are exactly of that kind. However, we've some more no-herd'ed packages to put into this new potential c++ herd - but these are two different discussions/threads IMHO. Regards, Christian Parpart. pgpmomqy0QfGN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Fri, Sep 16, 2005 at 06:20:57PM -0400, Mark Loeser wrote: dev-util/flawfinder (no-herd, aliz?) dev-util/rats (no-herd, robbat2) I'm a large user of these, but for rats there really isn't any maintaining to do, upstream hasn't changed the code in 18+ months, and it works fine still. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpNTOYbdsKeD.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote: C++ herd is a good idea, especially with that number of packages. I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 01:20, Mike Frysinger wrote: On Friday 16 September 2005 06:20 pm, Mark Loeser wrote: Since we currently have language herds for other languages such as Ada, Perl, and Java, I don't think C++ should be any different. it is different, but i dont mind the idea of having a bunch of C++ experts looking over a bunch of packages which otherwise may be neglected And that's the point I see in as well - having some central point for our C++ experts/freaks. Of course, a c++ herd would not just be like ADA/Java IMO. Though, I vote FOR such a herd (and would like to join anyway) dev-libs/STLport(no-herd, vapier?) vapier/toolchain dev-libs/fampp2 (no-herd, vapier) dev-libs/ferrisloki (no-herd, vapier) dev-libs/libferrisstreams (no-herd, vapier) dev-db/stldb4 generally i dont need help with these as the upstream author is a pretty cool guy and gets back to me :) -mike but having some backup is always the safer way, in case some of us is AFK for some unobvious reasons and a security patch is to be injected. Regards, Christian Parpart pgpUVooVe8STE.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote: On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote: C++ herd is a good idea, especially with that number of packages. I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? indeed, it at least helps curious c++ devs to browse through some yet unknown c++ libs and he maybe finds something useful. Regards, Christian Parpart. pgpzHaXkO28CW.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On 17/9/2005 13:33:30, Christian Parpart ([EMAIL PROTECTED]) wrote: On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote: On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote: C++ herd is a good idea, especially with that number of packages. I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? indeed, it at least helps curious c++ devs to browse through some yet unknown c++ libs and he maybe finds something useful. If the only gain is that one group finds one search criteria a little easier, then I think that is far from sufficient reason to re-categorise. What about people searching in the application domain (which to be honest I think is much more likely)? Under your approach they have to rummage around in each dev-lang category, hoping that it'll be obvious from the package name that it's suitable for their application domain. What happens when the media, games or net herds come along, and want to pull stuff into a media-libs, dev-games, net-libs? We end up in a tug-of-war between competing interests. Think also of all the work involved in re-categorising stuff; how everyone with dependencies on these packages in their overlay will have to rework stuff in their overlay, all because of one group's nice-to-have. It's particularly acute for libraries. I think we should discourage the idea that filesystem categories and herds are related at all, and think of filesystem categories simply as convenient buckets preventing lists of packages getting long. Resist the urge to re-categorise as much as possible, because in the end it's pointless. Instead, add to metadata, and use that to find stuff. In metadata.xml, we could have as many search criteria as we like; for example source language(s), library|application, application domain (sound, games, video) which can happily cope with many-many relationships. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 14:01, Kevin F. Quinn wrote: On 17/9/2005 13:33:30, Christian Parpart ([EMAIL PROTECTED]) wrote: On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote: On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote: C++ herd is a good idea, especially with that number of packages. I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? indeed, it at least helps curious c++ devs to browse through some yet unknown c++ libs and he maybe finds something useful. If the only gain is that one group finds one search criteria a little easier, then I think that is far from sufficient reason to re-categorise. errr... I didn't meant of course == indeed, I meant it a way of that might make sense. sorry for the misunderstandings ;) Regards, Christian. pgpofgnAw5U4n.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Kevin F. Quinn wrote: I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? The reason for me adding that bit is the metadata from dev-cpp: The dev-cpp category contains libraries and utilities relevant to the c++ programming language. Now to me, that means I can find *all* relevant C++ stuff here. If we don't want that to be the case, maybe we should say miscellaneous, but why should something be in dev-libs, as compared with dev-cpp? net-libs, I could understand, and dev-games, as those could be argued to have a direct relation. This is really just a matter of categorization, and isn't as big of a concern for me as it is trying to put all of these no-herd packages under a herd. Mark signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote: Kevin F. Quinn wrote: I would also like to see many of them, if not all, moved to the dev-cpp category: Is this bit really necessary? The reason for me adding that bit is the metadata from dev-cpp: The dev-cpp category contains libraries and utilities relevant to the c++ programming language. Now to me, that means I can find *all* relevant C++ stuff here. If we don't want that to be the case, maybe we should say miscellaneous, but why should something be in dev-libs, as compared with dev-cpp? net-libs, I could understand, and dev-games, as those could be argued to have a direct relation. for generic C++ packages (STLport/boost for example), i can see them being in the dev-cpp category ... but for packages which have specific uses already and arent in 'generic' categories, i dont think they should be moved -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
Mike Frysinger wrote: On Saturday 17 September 2005 02:22 pm, Mark Loeser wrote: The reason for me adding that bit is the metadata from dev-cpp: The dev-cpp category contains libraries and utilities relevant to the c++ programming language. Now to me, that means I can find *all* relevant C++ stuff here. If we don't want that to be the case, maybe we should say miscellaneous, but why should something be in dev-libs, as compared with dev-cpp? net-libs, I could understand, and dev-games, as those could be argued to have a direct relation. for generic C++ packages (STLport/boost for example), i can see them being in the dev-cpp category ... but for packages which have specific uses already and arent in 'generic' categories, i dont think they should be moved I agree with this, but I think dev-libs and dev-util are generic categories, and moving these packages from there would help users in finding what they need. I think this is what you are saying atleast :) Mark signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] C++ herd proposal
Since we currently have language herds for other languages such as Ada, Perl, and Java, I don't think C++ should be any different. There are currently many packages in the tree that are C++ libraries or utilities that are no-herd and are actively maintained, and there are probably some that have just been sitting around rotting. With the creation of a C++ herd, there would be a team that could support these packages, instead of a single maintainer, if the package has one. Below is a list of all of the packages that I believe would qualify as falling under this herd. If you see your name in the following list, I'd especially like to hear from you. Names with a '?' next to them are packages that had no metadata and I guessed from the changelog who the maintainer is. I would also like to see many of them, if not all, moved to the dev-cpp category: dev-cpp/commoncpp2 (no-herd, arj) dev-cpp/gccxml (no-herd, g2boojum) dev-cpp/libibinio (no-herd, spock) dev-cpp/poslib (no-herd, matsuu) dev-cpp/rudiments (no-herd, matsuu) dev-db/libodbc++(no-herd, robbat2) dev-libs/STLport(no-herd, vapier?) dev-libs/asyncresolv(no-herd, jhhudso?) dev-libs/blitz (no-herd, dragonheart) dev-libs/boost (no-herd, morfic) dev-libs/cgicc (no-herd, ka0ttic) dev-libs/commonc++ (duplicate of dev-cpp/commoncpp2 as far as I can tell, unmaintained?) dev-libs/darts (no-herd, unmaintained?) dev-libs/dvacm4 (no-herd, pvdabeel?) dev-libs/dvcgi (no-herd, ka0ttic) dev-libs/dvutil (no-herd, ka0ttic) dev-libs/fampp2 (no-herd, vapier) dev-libs/ferrisloki (no-herd, vapier) dev-libs/ibpp (no-herd, sekretarz) dev-libs/korelib(no-herd, george?) dev-libs/libcoyotl (no-herd, aliz) dev-libs/libevocosm (no-herd, aliz) dev-libs/libferrisstreams (no-herd, vapier) dev-libs/log4cpp(no-herd, george?) dev-libs/log4cxx(no-herd, ka0ttic) dev-libs/luabind(no-herd, rphillips) dev-libs/ntl(no-herd, george?) dev-libs/pcre++ (no-herd, eradicator) dev-libs/ptypes (no-herd, dragonheart? george?) dev-libs/quantlib (no-herd, vanquirius) dev-libs/rlog (no-herd, vanquirius) dev-libs/socketstream (no-herd, george? dragonheart?) dev-libs/sucs (no-herd, ka0ttic) dev-libs/swl(no-herd, trapni upstream dead? The site appears to be dead) dev-libs/wefts (no-herd, flameeyes) dev-libs/xerces-c (no-herd, halcy0n) dev-libs/xmlwrapp (no-herd, ka0ttic) dev-libs/yaz++ (no-herd, robbat2) dev-util/leaktracer (no-herd, svyatogor?) net-libs/socket++ (no-herd, ka0ttic) Possible candidates (most of these are for C and C++): dev-libs/nana (no-herd, pyrania?) dev-libs/xmlrpc-c (no-herd, jhhudso) dev-libs/xxl(no-herd, ka0ttic) dev-util/astyle (no-herd, karltk) dev-util/bcpp (no-herd, chriswhite?) dev-util/ (no-herd, dragonheart?) dev-util/ccmalloc (no-herd, dholm) dev-util/cdecl (no-herd, phosphan) dev-util/cweb (no-herd, no one) dev-util/flawfinder (no-herd, aliz?) dev-util/rats (no-herd, robbat2) Currently under another herd, but seems to make more sense here: dev-cpp/libxmlpp(gnome-mm, ka0ttic) dev-cpp/sptk(desktop-misc, iluxa?) dev-libs/libsigc++ (gnome-mm, ka0ttic) dev-libs/libsigcx (gnome-mm, ka0ttic) dev-libs/mxmlplus (text-markup, usata) dev-libs/xplc (net-dialup, mrness) dev-util/cppunit(lang-misc, george?) dev-util/qtunit (kde, centic?) net-libs/wvstreams (net-dialup, mrness?) I would like all of the current maintainers of these packages to keep maintaining them, and they wouldn't be required to join the cpp team, but there are a few people that seem to maintain quite a few C++ libraries that might be interested in joining. If there is not a very good reason against the creation of this herd, I would like to do so in the coming week. As for the name, cpp may be a little misleading, any better suggestions? In the list above, I have libraries for C++, as well as utilities. Thanks, Mark signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Friday 16 September 2005 06:20 pm, Mark Loeser wrote: Since we currently have language herds for other languages such as Ada, Perl, and Java, I don't think C++ should be any different. it is different, but i dont mind the idea of having a bunch of C++ experts looking over a bunch of packages which otherwise may be neglected dev-libs/STLport(no-herd, vapier?) vapier/toolchain dev-libs/fampp2 (no-herd, vapier) dev-libs/ferrisloki (no-herd, vapier) dev-libs/libferrisstreams (no-herd, vapier) dev-db/stldb4 generally i dont need help with these as the upstream author is a pretty cool guy and gets back to me :) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
Mark Loeser wrote: Since we currently have language herds for other languages such as Ada, Perl, and Java, I don't think C++ should be any different. There are currently many packages in the tree that are C++ libraries or utilities that are no-herd and are actively maintained, and there are probably some that have just been sitting around rotting. With the creation of a C++ herd, there would be a team that could support these packages, instead of a single maintainer, if the package has one. Below is a list of all of the packages that I believe would qualify as falling under this herd. If you see your name in the following list, I'd especially like to hear from you. Names with a '?' next to them are packages that had no metadata and I guessed from the changelog who the maintainer is. I would also like to see many of them, if not all, moved to the dev-cpp category: snip I'm game. -- Who's scruffy-looking? -- Han Solo Aaron Walker [EMAIL PROTECTED] [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
On Fri, 16 Sep 2005 18:20:57 -0400 Mark Loeser [EMAIL PROTECTED] wrote: | Since we currently have language herds for other languages such as | Ada, Perl, and Java, I don't think C++ should be any different. | There are currently many packages in the tree that are C++ libraries | or utilities that are no-herd and are actively maintained, and there | are probably some that have just been sitting around rotting. With | the creation of a C++ herd, there would be a team that could support | these packages, instead of a single maintainer, if the package has | one. Below is a list of all of the packages that I believe would | qualify as falling under this herd. If you see your name in the | following list, I'd especially like to hear from you. Names with a | '?' next to them are packages that had no metadata and I guessed from | the changelog who the maintainer is. I would also like to see many of | them, if not all, moved to the dev-cpp | category: I use some of those. Count me in, so long as I don't ever have to touch the hideous monstrosity that is boost... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp1ISw7SmNLF.pgp Description: PGP signature
