Re: [gentoo-dev] [RFC] C++ herd proposal

2005-09-20 Thread Alin Nastac
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

2005-09-20 Thread Georgi Georgiev
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

2005-09-20 Thread Alin Nastac
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

2005-09-20 Thread Martin Schlemmer
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

2005-09-20 Thread Brian Harring
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

2005-09-20 Thread Donnie Berkholz

-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

2005-09-19 Thread Paul de Vrieze
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

2005-09-19 Thread Mark Loeser

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

2005-09-19 Thread warnera6

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

2005-09-19 Thread Christian Parpart
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

2005-09-19 Thread Georgi Georgiev
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

2005-09-18 Thread Christian Parpart
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

2005-09-17 Thread Robin H. Johnson
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

2005-09-17 Thread Kevin F. Quinn
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

2005-09-17 Thread Christian Parpart
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

2005-09-17 Thread Christian Parpart
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

2005-09-17 Thread Kevin F. Quinn
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

2005-09-17 Thread Christian Parpart
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

2005-09-17 Thread Mark Loeser
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

2005-09-17 Thread Mike Frysinger
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

2005-09-17 Thread Mark Loeser
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


Re: [gentoo-dev] [RFC] C++ herd proposal

2005-09-16 Thread Mike Frysinger
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

2005-09-16 Thread Aaron Walker

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

2005-09-16 Thread Ciaran McCreesh
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