[gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 6525 bytes --]

All,

Hi, it's your favorite cashew dev Chris.  It's come to my attention that 
media-sound is FREAKING HUGE (like this email)!  I've found that when 
people ask me "Hey Chris!  What's a good mp3 alternative to xmms!", I 
often find myself saying "Let me browse a couple thousand packages to 
give you a good idea!".  Yah right!  Like I have time for that! Here's a 
nice plan I spat out (this was done awhile ago, so it might be missing a 
couple of packages :P).  This includes categories and packages.

sound-streaming: programs that deal with sound over network
sound-players: mp3/cd/anything players go here
sound-filtering: anything that filters or adds effects (I consider 
effects "filters", but maybe that's just me) to audio
sound-radio: this deals with both internet and fm radio cards
sound-drivers: drivers for soundcards
sound-dj: programs for dj-ing or playlist creation/management
sound-management: programs that sort/manage mp3 files
sound-midi: programs that deal with midi
sound-portable: programs/drivers that interface with portable music devices
sound-mixers: programs that act as mixers for alsa/oss/anything
sound-dev: there were some packages that create sound through scripting 
language, or create sound applications, those went here.
sound-accessibility: voice recognition software went here.  I'm thinking 
of taking a lot of programs from app-accessibility and moving them here.
sound-instruments: anything that does instrument tunning or emulates 
instruments
sound-encoders: anything that encodes/converts to mp3/ogg/whatever
sound-sheet: programs that deal with sheet music notation/reading
sound-editors: programs that edit audio files
sound-rippers: programs that rip audio from a source
sound-daemons: sound server programs go here
sound-taggers: programs that deal with audio file tagging (ie. id3 tags)
sound-synth: sound synthesizer programs
sound-tools: programs that don't fall into the above categories.  I 
consider this the "misc" section.
sound-data: places for drum kits/sound presets/etc.

sound-streaming
    -acast
    -bossogg
    -daapd
    -darkice
    -daudio
    -edna
    -erec
    -gini
    -gnump3d
    -imp3sh
    -litestream
    -mimd
    -mserv
    -muse
    -rat
    -rplay
    -shoutcast-server-bin
    -shoutcast-trans-bin
    -teamspeak2-client-bin
    -teamspeak2-server-bin
    -ventrilo-server-bin
    -icecast
    -ices
sound-players
    -adplay
    -alsaplayer
    -amarok
    -amp
    -apollo
    -aylet
    -beep-media-player
    -bplay
    -cdcd
    -cdplay
    -cplay
    -dcd
    -digitaldj
    -glurp
    -gmpc
    -gqmpeg
    -kmp
    -liteamp
    -madplay
    -mcdp
    -mikmod
    -moc
    -moosic
    -mp3blaster
    -mpc
    -mpfc
    -mpg123
    -mpg321
    -mplay
    -mucke
    -muine
    -ncmpc
    -noxmms
    -orpheus
    -playspc_gtk
    -quark
    -rawrec
    -rhythmbox
    -sexypsf
    -sidplay
    -sonic-rainbow
    -splay
    -squelch
    -takcd
    -tunesbrowser
    -waif
    -wavplay
    -xmms
    -xmp
    -zinf
sound-filtering
    -aseqview
    -brutefir
    -creox
    -ecamegapedal
    -jack-rack
    -tapiir
sound-radio
    -fmtools
    -gnomeradio
    -gnomoradio
    -gqradio
    -gradio
    -kradio
sound-drivers
    -alsa-driver
    -alsa-firmware
    -alsa-headers
    -alsa-patch-bay
    -emu10k1
    -fobbit
    -nforce-audio
    -rcenter
    -sbconf
    -sulu
sound-DJ
    -DBMix
    -bpmdj
    -fapg
    -mixxx
sound-management
    -cd-discid
    -cdtool
    -kmusicdb
    -longplayer
    -madman
    -mp3kult
    -mp3mover
    -prokyon3
    -radiostation
    -wavesurfer
    -yammi
sound-midi
    -fmdrv
    -museseq
    -playmidi
    -pmidi
    -rosegarden
    -seq24
    -specimen
    -timidity++
    -timidity-eawpatches
    -timidity-shompatches
sound-mp3players
    -gnomad
    -positron
    -usbmidi
sound-mixers
    -alsamixergui
    -aumix
    -cmix
    -ermixer
    -gamix
    -gnome-alsamixer
    -gom
    -kamix
    -knob
    -opmixer
    -psmix
    -rexima
    -setmixer
    -smixer
    -umix
sound-dev
    -cm
    -demolition
    -galan
    -gsm
    -jmax
sound-accessibility
    -cvoicecontrol
    -saydate
sound-instruments
    -gtkguitune
    -horgand
    -hydrogen
    -k3guitune
    -psindustrializer
    -trommler
    -vkeybd
sound-encoders
    -ardour
    -audiocompress
    -bladeenc
    -gogo
    -lame
    -mp32ogg
    -musepack-tools
    -shorten
    -streamtranscoder
    -toolame
    -vlorb
    -wavpack
sound-sheet
    -abcm2ps
    -denemo
    -lilypond
    -mup
    -musescore
    -noteedit
    -scret
sound-editors
    -audacity
    -cheesetracker
    -ecasound
    -glame
    -gnusound
    -gramofile
    -jamin
    -mhwaveedit
    -pd
    -protux
    -rezound
    -snd
    -sox
    -sweep
sound-rippers
    -abcde
    -cdmp3
    -cdparanoia
    -cdstatus
    -choad
    -grip
    -gstreamripper
    -icecream
    -jack
    -kstreamripper
    -mp3c
    -rip
    -ripperx
    -sound-juicer
    -streamripper
    -xmcd
sound-daemons
    -esound
    -jack-audio-connection-kit
    -mpd
sound-data
    - all the hydrogen kits I'm about to commit :P
sound-taggers
    -SmarTagger
    -audiotag
    -cantus
    -easytag
    -id3
    -id3ed
    -id3tool
    -id3v2
    -kid3
    -mp3info
    -musicman
    -qmbtagger
    -tagtool
sound-synth
    -ams
    -amsynth
    -beast
    -beast-data
    -fluidsynth
    -freebirth
    -gmorgan
    -qsynth
    -sfc
    -smurf
    -spiralmodular
    -swami
    -terminatorx
    -zynaddsubfx
sound-tools
    -albumart
    -alsa-tools
    -alsa-utils
    -audio-entropyd
    -awesfx
    -bitscope
    -ctrlxmms
    -extace
    -freqtweak
    -glmix
    -gtick
    -hearnet
    -kaconnect
    -krecord
    -meterbridge
    -mp3_check
    -mp3asm
    -mp3check
    -mp3gain
    -mp3splt
    -mp3wrap
    -normalize
    -oggtst
    -ogmtools
    -ptabtools
    -qjackconnect
    -qjackctl
    -shntool
    -solfege
    -soundtracker
    -ssrc
    -streamixer
    -synaesthesia
    -tempest_for_eliza
    -timemachine
    -trm
    -vorbis-tools
    -vorbisgain
    -vsound
    -wavbreaker
    -wavsplit
    -wmsound-data
    -xmmsctrl
    -yconsole

That's all, now go ahead and comment / whatever.  However, if you say "I 
think it's a good idea to not organize those 20 billion packages in 
media-sound", I'll probably slap you with a wet flounder, close my ears 
and say "hear no evil"!  Peace :P.

-- 
Chris White <chriswhite@gentoo.org>
------------------------
Sound   | Video   | Security
Mozilla | Haskell | Lang-misc
ChrisWhite @ irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Patrick Lauer]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

I like that idea very much. Until we have a multi-level hierarchy
(/usr/portage/sound/mixer/foo-mix or similar) this is the sanest way of
handling it.

The only thing that might get difficult with that is the increasing
number of top-level categories. Any ideas how to keep them from
multiplying or getting them organized in a better structure?

Patrick

On Mon, 2004-11-08 at 05:36 +0900, Chris White wrote:
> All,
> 
> Hi, it's your favorite cashew dev Chris.  It's come to my attention that 
> media-sound is FREAKING HUGE (like this email)!  I've found that when 
> people ask me "Hey Chris!  What's a good mp3 alternative to xmms!", I 
> often find myself saying "Let me browse a couple thousand packages to 
> give you a good idea!".  Yah right!  Like I have time for that! Here's a 
> nice plan I spat out (this was done awhile ago, so it might be missing a 
> couple of packages :P).  This includes categories and packages.
[SNIP]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[M. Edward Borasky]

On Sun, 2004-11-07 at 12:59, Patrick Lauer wrote:
> I like that idea very much. Until we have a multi-level hierarchy
> (/usr/portage/sound/mixer/foo-mix or similar) this is the sanest way of
> handling it.

Yeah ... I almost said we need a multi-level hierarchy but held off
because I don't know enough about Portage to know whether it's possible
or desirable. I do think we need multi-level.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[M. Edward Borasky]

On Sun, 2004-11-07 at 12:36, Chris White wrote:
> All,
> 
> Hi, it's your favorite cashew dev Chris.  It's come to my attention that 
> media-sound is FREAKING HUGE (like this email)!  I've found that when 
> people ask me "Hey Chris!  What's a good mp3 alternative to xmms!", I 
> often find myself saying "Let me browse a couple thousand packages to 
> give you a good idea!".  Yah right!  Like I have time for that! Here's a 
> nice plan I spat out (this was done awhile ago, so it might be missing a 
> couple of packages :P).  This includes categories and packages.

[snip]

> That's all, now go ahead and comment / whatever.  However, if you say "I 
> think it's a good idea to not organize those 20 billion packages in 
> media-sound", I'll probably slap you with a wet flounder, close my ears 
> and say "hear no evil"!  Peace :P.

1. Re-organizing "media-sound" is an *excellent* idea! One of my
principal reasons for getting into Linux in the first place was for
audio work. "media-sound" is a jungle at present.

2. I would divide it along these lines:

   a. Core tools -- things like alsa, jack-audio-connection-kit, mixers,
timidity, sox, etc. -- stuff *everyone* needs

   b. Synthesis and Digital Signal Processing -- all the synthesizers,
wave editors, etc.

   c. Media players, radio, CDs, encoders, streamers, etc.

   d. Music processing: rosegarden, lilypond, common music, jMax,
puredata, etc. -- high-level tools for music and algorithmic
composition. And I would add some packages to this category: csound,
cecilia, Common Lisp Music, Common Music Notation, Athena and sfront. If
the licensing works, OpenMusic should be in here too.

The "gold standard" for Linux studio musicians is the Debian-based
Agnula distro. Their "social contract" is perhaps a tad more restrictive
than Gentoo's, since they are based in Europe, but they have or are
working on just about everything I need as a studio musician/algorithmic
composer.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Mon, 08 Nov 2004 05:36:02 +0900 Chris White <chriswhite@gentoo.org>
wrote:
| That's all, now go ahead and comment / whatever.  However, if you say
| "I think it's a good idea to not organize those 20 billion packages in
| media-sound", I'll probably slap you with a wet flounder, close my
| ears and say "hear no evil"!  Peace :P.

Too many categories. TOOOO MAAAANNNNYYY CATEGORIES!!! Split 'em up,
sure, but don't go overboard... 20 to 50 packages per toplevel is
probably a reasonable target.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On Sunday 07 November 2004 22:05, Ciaran McCreesh wrote:
> Too many categories. TOOOO MAAAANNNNYYY CATEGORIES!!! Split 'em up,
> sure, but don't go overboard... 20 to 50 packages per toplevel is
> probably a reasonable target.

I absolutely agree. Have a look at the number of ebuilds in net-misc, before 
caring for your ebuilds of interest, please. :|


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Stuart Herbert]

On Sunday 07 November 2004 21:46, Carsten Lohrke wrote:
> I absolutely agree. Have a look at the number of ebuilds in net-misc,
> before caring for your ebuilds of interest, please. :|

net-misc is the perfect example of why additional categories are a *good* 
idea.  Not only is it difficult to see what's available, but places like that 
simply become a huge dumping ground for unmaintained ebuilds.

If Portage supporting arbitrary-depth category trees, then we could organise 
things a lot easier.  But until that happens, devs are going to have to 
accept the need for more directories in /usr/portage.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[M. Edward Borasky]

On Sun, 2004-11-07 at 13:39, Stuart Herbert wrote:
> On Sunday 07 November 2004 21:46, Carsten Lohrke wrote:
> > I absolutely agree. Have a look at the number of ebuilds in net-misc,
> > before caring for your ebuilds of interest, please. :|
> 
> net-misc is the perfect example of why additional categories are a *good* 
> idea.  Not only is it difficult to see what's available, but places like that 
> simply become a huge dumping ground for unmaintained ebuilds.

Speaking of "net-misc", I think "iperf" should move out of net-misc and
into net-analyzer, where it can join its cousin "netperf".



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

Sorry, Stuart. KMail sucks, so you'll get this email twice. 
On Sunday 07 November 2004 22:39, Stuart Herbert wrote:
> net-misc is the perfect example of why additional categories are a *good*
> idea.  Not only is it difficult to see what's available, but places like
> that simply become a huge dumping ground for unmaintained ebuilds.

I don't say anything else. Just categories with e.g. only a dozen ebuilds 
shouldn't be created.

> If Portage supporting arbitrary-depth category trees, then we could
> organise things a lot easier.  But until that happens, devs are going to
> have to accept the need for more directories in /usr/portage.

I don't think an arbitrary depths would be so helpful. Most likely it'd 
slowdown portage. How about flatten the whole beast!? The categorization 
hasn't to be done via directories.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[George Shapovalov]

On Sunday 07 November 2004 14:29, Carsten Lohrke wrote:
> Sorry, Stuart. KMail sucks, so you'll get this email twice.
> I don't think an arbitrary depths would be so helpful. Most likely it'd
> slowdown portage. How about flatten the whole beast!? The categorization
> hasn't to be done via directories.

By what, 1% or less? (according to what I remember portage devs were saying 
90% of the time is spent in bash anyway). Instead we will improve or at least 
regain browseability of the tree. Searches are good (and we can get multiple 
categorization that way as well), but if we can have both then why not? 

George


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Sunday 07 November 2004 23:53, George Shapovalov wrote:
> By what, 1% or less? (according to what I remember portage devs were saying
> 90% of the time is spent in bash anyway).

This was an assumption, based on the fact that you can expect all 
subdirectories of categories to be package directories right now. When you 
write a tool supporting _arbitrary_ depths you'd need to walk down the tree 
and check for e.g. Manifest files all the time. I'm not familiar with the 
Portage code, so someone else is welcome to give an exhausting answer. Also I 
put portage caching aside, just would like to see a version that _really_ 
works. 

I general I don't think that arbitrary depths lower the complexity to find a 
specific package. Most likely it will raises the complexity of the Portage 
code quite a bit, though.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

maillog: 08/11/2004-18:29:10(+0100): Carsten Lohrke types
> On Sunday 07 November 2004 23:53, George Shapovalov wrote:
> > By what, 1% or less? (according to what I remember portage devs were saying
> > 90% of the time is spent in bash anyway).
> 
> This was an assumption, based on the fact that you can expect all 
> subdirectories of categories to be package directories right now. When you 
> write a tool supporting _arbitrary_ depths you'd need to walk down the tree 
> and check for e.g. Manifest files all the time. I'm not familiar with the 
> Portage code, so someone else is welcome to give an exhausting answer. Also I 
> put portage caching aside, just would like to see a version that _really_ 
> works. 

Portage has a list of all categories ($PORTDIR/profiles/categories), so
walking down the tree and looking here or there whether what you see is
a category or not, is not an issue.

> I general I don't think that arbitrary depths lower the complexity to find a 
> specific package. Most likely it will raises the complexity of the Portage 
> code quite a bit, though.

To me, it seems that it should be trivial.

-- 
*)   Georgi Georgiev   *) We are governed not by armies and police     *)
(*    chutz@gg3.net    (* but by ideas. -- Mona Caird, 1892            (*
*)  +81(90)6266-1163   *)                                              *)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Tuesday 09 November 2004 04:56, Georgi Georgiev wrote:
> Portage has a list of all categories ($PORTDIR/profiles/categories), so
> walking down the tree and looking here or there whether what you see is
> a category or not, is not an issue.

Indeed. Did not notice that yet.

> > I general I don't think that arbitrary depths lower the complexity to
> > find a specific package. Most likely it will raises the complexity of the
> > Portage code quite a bit, though.
>
> To me, it seems that it should be trivial.

With the categories stored in a file, yes. Seems I missed the discussion, but 
I still don't see a benefit in arbitrary depths categories.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Ed Grimm]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3472 bytes --]

On Sun, 7 Nov 2004, Carsten Lohrke wrote:

> On Sunday 07 November 2004 22:39, Stuart Herbert wrote:
>> If Portage supporting arbitrary-depth category trees, then we could
>> organise things a lot easier.  But until that happens, devs are
>> going to have to accept the need for more directories in
>> /usr/portage.
>
> I don't think an arbitrary depths would be so helpful. Most likely
> it'd slowdown portage. How about flatten the whole beast!? The
> categorization hasn't to be done via directories.

Whyever would flat-tree be better than arbitrary-depth?

When I started being more dilligent about reading the gentoo mailing
lists, I saw a number of threads on the topic of adding sub-categories,
and the only consistent reason that was given for not moving forward
was, "we need to benchmark that."

Initially, I saw this as a good thing, because while I already knew the
answer, performing tests to verify what one suspects tends to be a good
thing.  However, as time went on, I continued not seeing the benchmarks.
After a while, I became disheartened.  But there were other things I was
wanting to focus on, so I didn't get invovled.


However, knowing the answer to the directory performance question, I
could not let this comment alone.

I've attached a benchmark script, written in perl, which will find all
of the files in the specified directory tree(s), and then randomly
selects [count] files (where count is either specified by the --count
option, or 10,000), and reads the first line of each of these files.
This script can be utilized to benchmark any directory layout methods
that people wish to consider for Gentoo.

What they will find is: for ext2 and ext3 systems, there is an optimal
number of files per directory, performance falls linearly beyond this
point; for reiserfs systems, it doesn't matter.

I performed my own tests with this script; doing a split at the most
obvious point (the - in the category names), I received marginally
*improved* performance - Gentoo is already slightly over the optimal
number of files in /usr/portage.  (Don't get me started on dev-perl.)

More specifically, my average time for 10,000 random file reads in
/usr/portage (by changing to /usr/portage and using '.' as the argument
to benchaccess) was a little over 60 seconds, although as more tests were
performed, the Linux file cache started optimizing that result.  My
average time for the split categories, on the other hand, averaged at 55
seconds.


Some people may wonder why this is - after all, to access multiple
directory trees is clearly a lot more work.  This may be true for a
human, but the computer doesn't see it that way - under ext2 and ext3,
it has to read all of the filenames in the directory, until it finds the
one you're looking for.  Having fewer files, but more directories, means
that it gets to the file at each level much quicker.  Each of the
directory changes adds some time, but that's negligable compared to the
time it takes to read through a large directory.  Note that this, of
course, assumes that sanity is maintained, and we don't have many
categories or subcategories with fewer than a dozen packages and/or
subcategories.

Another way to think of it, it's similar to the difference between
searches on an unsorted array, and searches on a sorted array.

Anyone who wonders why reiserfs does not have an issue with either
layout does not know what reiserfs is - it was designed specifically to
avoid this problem.

Ed

[-- Attachment #2: Type: TEXT/PLAIN, Size: 701 bytes --]

#!/usr/bin/perl -w

use File::Find();
use Time::HiRes qw(time);
use Getopt::Long();

#if (do "Time/HiRes.pm") {
#    Time::HiRes->import('time');
#}

my @files;
my $count = 10000;
my $line;

{
    my %opt = (
	    'count|c=i' => \$count,
	);

    Getopt::Long::GetOptions(%opt);
}

sub findfiles {
    if (-e $_ && ! -d _) {
	push @files, $File::Find::name;
    }
}

File::Find::find(\&findfiles, @ARGV);

my $start = time();
while ($count--) {
    $file = $files[rand(@files)];
    open(READ, "<$file") or die "Cannot open file $file: $!\n";
    $line = <READ>;
    close(READ);
}

my $time = time() - $start;

print "Process took $time seconds.\n";
exit 0;

[-- Attachment #3: Type: text/plain, Size: 37 bytes --]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Jason Rhinelander]

Ed Grimm wrote:
 > What they will find is: for ext2 and ext3 systems, there is an optimal
 > number of files per directory, performance falls linearly beyond this
 > point; for reiserfs systems, it doesn't matter.

Did you test this with a dir_index-enabled ext2/3 as well?

-- Jason Rhinelander
-- Gossamer Threads, Inc.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Monday 08 November 2004 05:31, Ed Grimm wrote:
> Whyever would flat-tree be better than arbitrary-depth?

This was a bit theoretical to set a counterpoint to the arbitrary depths idea. 
I neither put a thought on the implications regarding different fs or cvs. 
One benefit would be, that it would force us to have unique package names; 
Something like the output of `emerge texinfo` wouldn't happen. Also the 
metadata wouldn't need to go away. Just the representation via directories. 
If this would be done via keywords (not the arch ones), then everyone could 
use (either cli or more powerful graphical) tools to represent sets of 
packages in many ways.

The real reason for the anserer is that I don't think, that it will be easier 
to find packages, by hiding them in fourth or fifths level subdirectories. 
Especially, if the depths can differ.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Colin Kingsley]

On Sun, 7 Nov 2004, Carsten Lohrke wrote:
> metadata wouldn't need to go away. Just the representation via directories.
> If this would be done via keywords (not the arch ones), then everyone could
> use (either cli or more powerful graphical) tools to represent sets of
> packages in many ways.

I'm a big fan of this idea. With a good tool to browse by category,
this would be ideal. As an added bonus, a package could belong to
multiple categories without duplicating the ebuild in the tree.

Colin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

On Monday 08 November 2004 05:31, Ed Grimm wrote:
> On Sun, 7 Nov 2004, Carsten Lohrke wrote:
> > On Sunday 07 November 2004 22:39, Stuart Herbert wrote:
> >> If Portage supporting arbitrary-depth category trees, then we could
> >> organise things a lot easier.  But until that happens, devs are
> >> going to have to accept the need for more directories in
> >> /usr/portage.
> >
> > I don't think an arbitrary depths would be so helpful. Most likely
> > it'd slowdown portage. How about flatten the whole beast!? The
> > categorization hasn't to be done via directories.
>
> Whyever would flat-tree be better than arbitrary-depth?
>
> When I started being more dilligent about reading the gentoo mailing
> lists, I saw a number of threads on the topic of adding sub-categories,
> and the only consistent reason that was given for not moving forward
> was, "we need to benchmark that."

I don't say that I don't like this idea, but we will undoubtedly encounter 
all kinds of bugs caused by tools/utilities that make assumptions about 
category depth.

Paul

ps. arbitrary depth should start with 1, not 0

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Karl Trygve Kalleberg]

On Monday 08 November 2004 05:31, Ed Grimm wrote:
> On Sun, 7 Nov 2004, Carsten Lohrke wrote:
> > On Sunday 07 November 2004 22:39, Stuart Herbert wrote:
> >> If Portage supporting arbitrary-depth category trees, then we could
> >> organise things a lot easier.  But until that happens, devs are
> >> going to have to accept the need for more directories in
> >> /usr/portage.
> >
> > I don't think an arbitrary depths would be so helpful. Most likely
> > it'd slowdown portage. How about flatten the whole beast!? The
> > categorization hasn't to be done via directories.
>
> Whyever would flat-tree be better than arbitrary-depth?
>
> When I started being more dilligent about reading the gentoo mailing
> lists, I saw a number of threads on the topic of adding sub-categories,
> and the only consistent reason that was given for not moving forward
> was, "we need to benchmark that."

As Paul also points out, assumptions about this one-depth scheme run deep into 
our tools.

We have hundreds of hand-written, practically unmaintained scripts lying about 
the system which must be changed to take this into account. Worse, these 
scripts are required for everyday operation of Gentoo, both by developers and 
users. 

Many (most?) of these are written in bash, a language with the several 
remarkable features, one of them being that writing recursive functions is a 
pain.

If you wanted to consider rolling out sub-categories, I very much think that 
for practical reasons, each package would need _one_ primary/canonical 
category of depth one.

-- Karl T

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On Tue, 2004-11-16 at 12:37 +0100, Karl Trygve Kalleberg wrote:
> Many (most?) of these are written in bash, a language with the several 
> remarkable features, one of them being that writing recursive functions is a 
> pain.

Don't bash bash... it's just... too funny.

> If you wanted to consider rolling out sub-categories, I very much think that 
> for practical reasons, each package would need _one_ primary/canonical 
> category of depth one.

I completely agree here.  Everything should be subjected to some form of
categorization.  Also, would we keep the same "major" categories (app,
dev, games, gnome, kde, media, net, (sound?,) sys, www, x11, xfce) or
would we devise a completely new set?  After all, *everything* would
probably fit under app, at least when sub-categories are possible.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Colin Kingsley]

On Tuesday, November 16, Karltk writes:
> Many (most?) of these are written in bash, a language with the several
> remarkable features, one of them being that writing recursive functions is a
> pain.

This is one more problem that would be avoided with a flat package
repository right?

Furthermore, I have a hunch that a flat structure would make it easier
in the future to move to a multiple repository system, a la debians
numerous apt repositories. I only mention this because I've been told
its one of our goals, I could be mistaken.


Colin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Tuesday 16 November 2004 17:50, Colin Kingsley wrote:
> On Tuesday, November 16, Karltk writes:
> > Many (most?) of these are written in bash, a language with the several
> > remarkable features, one of them being that writing recursive functions
> > is a pain.
>
> This is one more problem that would be avoided with a flat package
> repository right?
>
> Furthermore, I have a hunch that a flat structure would make it easier
> in the future to move to a multiple repository system, a la debians
> numerous apt repositories. I only mention this because I've been told
> its one of our goals, I could be mistaken.

Well, multiple repositories is inviting mayhem if there is any overlap between 
them, and possibly even when there is no overlap. The gentoo ebuilds are 
written in the assumption that only other gentoo ebuilds need to be taken 
into account (or that people know what they're doing with their overlays), 
not with the assumption that a lot of base libraries are going to be provided 
in another tree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Package sub-categories, directory performance, and benchmarking

[Colin Kingsley]

On Tue, 16 Nov 2004 21:57:01 +0100, Paul de Vrieze <pauldv@gentoo.org> wrote:
> 
> Well, multiple repositories is inviting mayhem if there is any overlap between
> them, and possibly even when there is no overlap. The gentoo ebuilds are
> written in the assumption that only other gentoo ebuilds need to be taken
> into account (or that people know what they're doing with their overlays),
> not with the assumption that a lot of base libraries are going to be provided
> in another tree.
> 
> Paul

Yea, I realise that there would be other issues involved with
supporting multiple repositories, I was only suggesting that a flat
directory structure would remove one such obstacle.

Although, from your response I'd assume that nobody, in fact, has any
intention of implementing multiple repositories.


Colin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[George Shapovalov]

On Sunday 07 November 2004 13:05, Ciaran McCreesh wrote:
> On Mon, 08 Nov 2004 05:36:02 +0900 Chris White <chriswhite@gentoo.org>
> Too many categories. TOOOO MAAAANNNNYYY CATEGORIES!!! Split 'em up,
> sure, but don't go overboard... 20 to 50 packages per toplevel is
> probably a reasonable target.

So, can we finally get something decided on arbitrary depth categories?

Not to put any additional pressure on portage devs, they are overworked as it 
is already, but just something like "yea, its a good thing, we can do it 
after such and such features are implemented" or "nah, we are going to just 
go with a flat list of packages in the future and resort to searches 
anyway" (to make both camps happy ;)). The tree, the way it is now, clearly 
does not scale.

George


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[M. Edward Borasky]

On Sun, 2004-11-07 at 14:12, George Shapovalov wrote:
> So, can we finally get something decided on arbitrary depth categories?
> 
> Not to put any additional pressure on portage devs, they are overworked as it 
> is already, but just something like "yea, its a good thing, we can do it 
> after such and such features are implemented" or "nah, we are going to just 
> go with a flat list of packages in the future and resort to searches 
> anyway" (to make both camps happy ;)). The tree, the way it is now, clearly 
> does not scale.
Hmmm ... Debian's tree is (roughly) twice as big, and their hierarchy is
also single-level (sections, they call them). Both Debian's and Gentoo's
are unusable without searching. In fact, Gentoo's is unusable without
"esearch"; that along with "ufed" ought to be in "stage3", don't you
think?


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[George Shapovalov]

On Sunday 07 November 2004 14:18, M. Edward Borasky wrote:
> On Sun, 2004-11-07 at 14:12, George Shapovalov wrote:
> > So, can we finally get something decided on arbitrary depth categories?
> Hmmm ... Debian's tree is (roughly) twice as big, and their hierarchy is
> also single-level (sections, they call them). Both Debian's and Gentoo's
> are unusable without searching. 
Searchability has its strong points, browsability has other strong points 
(say, you want to see what's available on certain topic. Searching for some 
word in the name ore description not always gives all the options..). I think 
we need both.
Besides this is not a new proposal. This topic was coming up quite a few times 
already, but never really decided upon. 

> In fact, Gentoo's is unusable without 
> "esearch"; that along with "ufed" ought to be in "stage3", don't you
> think?
Well, esearch has a separate database which has to be manually rebuilt, so 
this is a separate utility, although a prime candidate for gentoolkit. As for 
putting it into a stage3, not really sure either way.
WRT ufed, yea, but I would prefer seeing something a bit more organized 
there :) (with the ability to turn on/off local flags at least).

George


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Sun, 2004-11-07 at 14:18 -0800, M. Edward Borasky wrote:
> Hmmm ... Debian's tree is (roughly) twice as big, and their hierarchy is
> also single-level (sections, they call them). Both Debian's and Gentoo's
> are unusable without searching. In fact, Gentoo's is unusable without
> "esearch"; that along with "ufed" ought to be in "stage3", don't you
> think?

emerge -s and emerge -S work fine for me and there's no way ufed (which
doesn't work with cascading profiles last I checked) should be added
into any stage.  The packages in stage3 are *only* the "system"
packages.  Neither ufed nor esearch are required for a functioning
system.  I take my machines and my girlfriend's machine as prime
examples.  They are 100% functioning Gentoo machines and have neither
esearch nor ufed on them, nor have they ever.

-- 
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

George Shapovalov wrote:	[Sun Nov 07 2004, 05:12:02PM EST]
> So, can we finally get something decided on arbitrary depth categories?

I don't see how multi-tier categories makes things more findable
personally.  IMHO it just makes things more buried.  I like the
two-tier approach we have now:

    broad-narrow/pkgname

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[George Shapovalov]

I was first going to leave the thread at that, but I am feeling a bit 
graphomanic :). In any case I just wanted to say a few words describing 
"scientific" basis for multi-tier and hierarchies in general.

On Sunday 07 November 2004 15:47, Aron Griffis wrote:
> George Shapovalov wrote: [Sun Nov 07 2004, 05:12:02PM EST]
> I don't see how multi-tier categories makes things more findable
> personally.  IMHO it just makes things more buried.  I like the
> two-tier approach we have now:

Some recent philosophical, err :), psychological studies concluded that person 
normally deals best with 7-9 objects simultaneously. Less than that and you 
have to make your "chain of command" unnecessarily deep. More than that and 
you start spending more time searching around or trying to remember what 
every one of these these is about. (Don't remember where I saw it now; my 
wife is a psychologist, that's most likely where :)).

This is essentially the reason why we use hierarchies so widely. If every 
person was able to easily memorise and deal with indefinitely large lists we 
wouldn't be organizing stuff at all, why bother if you can just come in at 
any moment and pick exactly that regularly gray box of standard size in a big 
pile on the floor :). Now, that 7-9 is an average. I believe the deal is that 
every person has some individual "most effective number" but the distribution 
peaks somewhere in that range and is not very wide..

Incidentally we have exactly 8 major top-level categories ;) :
app-, dev-, games-, mail-, net-, sys-, www-, x11-

there are also a few which are essentially unitier, where there are only 1 or 
2 second-level's for every unique 1st level, gnustep-* seem to be the largest 
of all, with 3. But then we have a total of 127 categories, which is > 
9x9=81, so we wouldn't be able to follow that rule with two-tier already 
anyway. 
BTW, I don't think we really need to follow that rule for the leaves (I mean 
packages), we can easily stick to 40-50 max for example..

With that I am going to leave this thread and only post any more if there  
going to be a technicall discussion.

Oh, just one last thing :). I am about to propose yet another split. I think 
some people already know what I imply, but in any case stay tuned :).

George



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Sun, 7 Nov 2004 18:43:00 -0800 George Shapovalov <george@gentoo.org>
wrote:
| Some recent philosophical, err :), psychological studies concluded
| that person normally deals best with 7-9 objects simultaneously. Less
| than that and you have to make your "chain of command" unnecessarily
| deep. More than that and you start spending more time searching around
| or trying to remember what every one of these these is about. (Don't
| remember where I saw it now; my wife is a psychologist, that's most
| likely where :)).

That's when you're dealing with *short term* memory. Long term memory is
a whole different kettle of fish. Also, the 7 +- 2 that is usually
quoted is only valid for psychologists -- experiments on computer
science students here got 12 +- 2. Plus, it can be argued that the test
isn't relevant anyway, since it deals with unrelated items.

Actually, if we worked based upon the original study that that number
came from, what we'd have to do is only provide a small part of the
portage tree to new users and then gradually increase the selection as
time goes on. Which, clearly, we can't do...

Bleh. If anyone really cares I could go and dig up proper references and
so on. But really, this is all just hokey psych nonsense approximately
akin to eye of newt and leg of frog...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization! [shrink section]

[foser]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

On Sun, 2004-11-07 at 18:43 -0800, George Shapovalov wrote:
> Some recent philosophical, err :), psychological studies concluded that person 
> normally deals best with 7-9 objects simultaneously. Less than that and you 
> have to make your "chain of command" unnecessarily deep. More than that and 
> you start spending more time searching around or trying to remember what 
> every one of these these is about. (Don't remember where I saw it now; my 
> wife is a psychologist, that's most likely where :)).
> 
> This is essentially the reason why we use hierarchies so widely. If every 
> person was able to easily memorise and deal with indefinitely large lists we 
> wouldn't be organizing stuff at all, why bother if you can just come in at 
> any moment and pick exactly that regularly gray box of standard size in a big 
> pile on the floor :). Now, that 7-9 is an average. I believe the deal is that 
> every person has some individual "most effective number" but the distribution 
> peaks somewhere in that range and is not very wide..

Working memory is indeed about 7 items (people claiming much more are
most likely incorrectly tested). Hierarchies are useful allright, but
there are certainly better ways to interact with large quantities of
information, eg. visualizations, spatial information.

> Incidentally we have exactly 8 major top-level categories ;) :
> app-, dev-, games-, mail-, net-, sys-, www-, x11-

Well since it's all major-minor laid out, i think the effect of the 8
items is already growing weaker (you still get a listing of a few dozen
dirs). Plus the fact that the major category layout has sort of ad-hoc
evolved & as such has little meaning, there is clearly overlap in the
major categories already.

Personally i think the current lay-out is therefore not really fit to be
searched in a meaningful way. A more strict & deeper lay-out would help
in some sense, but also it introduces the problem of packages (and there
are a lot) that fit multiple categories. I don't think it's needed to
change the current existing lay-out to improve package searching, the
right way to go is abstract the rather random categories idea away by
creating a fast & smart searching tool.

- foser

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization! [shrink section]

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

foser wrote:	[Mon Nov 08 2004, 07:50:52PM EST]
> Personally i think the current lay-out is therefore not really fit to be
> searched in a meaningful way. A more strict & deeper lay-out would help
> in some sense, but also it introduces the problem of packages (and there
> are a lot) that fit multiple categories. I don't think it's needed to
> change the current existing lay-out to improve package searching, the
> right way to go is abstract the rather random categories idea away by
> creating a fast & smart searching tool.

I agree with this.  As foser says, changing the layout might help
some, but in my opinion it's not worthwhile.  Instead augment our
searching capability and make it possible, perhaps via metadata.xml,
to make category membership logical rather than physical.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Monday 08 November 2004 03:43, George Shapovalov wrote:
> I was first going to leave the thread at that, but I am feeling a bit
> graphomanic :). In any case I just wanted to say a few words describing
> "scientific" basis for multi-tier and hierarchies in general.
>
> On Sunday 07 November 2004 15:47, Aron Griffis wrote:
> > George Shapovalov wrote: [Sun Nov 07 2004, 05:12:02PM EST]
> > I don't see how multi-tier categories makes things more findable
> > personally.  IMHO it just makes things more buried.  I like the
> > two-tier approach we have now:
>
> Some recent philosophical, err :), psychological studies concluded that
> person normally deals best with 7-9 objects simultaneously. Less than that
> and you have to make your "chain of command" unnecessarily deep. More than
> that and you start spending more time searching around or trying to
> remember what every one of these these is about. (Don't remember where I
> saw it now; my wife is a psychologist, that's most likely where :)).

It's not really new ;-), and is one of the basic properties of cognition (so 
basic it's part of any good Human Computer Interaction course). It is 
actually similar with numbers. Without tricks an average person can not 
remember more than 7 digits (without using tricks to remember things with a 
hint). Some people can remember 9 digits, some even only 5 (it is related to 
inteligence, but only one of the factors. This is only for SHORT term memory, 
and for example also explains why a) long sentences confuse the hell out of 
people, and b) scientists tend to use long sentences (they normally have a 
good short term memory).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

On Tue, 9 Nov 2004 20:28:52 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > On Sunday 07 November 2004 15:47, Aron Griffis wrote:
| > > George Shapovalov wrote: [Sun Nov 07 2004, 05:12:02PM EST]
| > > I don't see how multi-tier categories makes things more findable
| > > personally.  IMHO it just makes things more buried.  I like the
| > > two-tier approach we have now:
| >
| > Some recent philosophical, err :), psychological studies concluded
| > that person normally deals best with 7-9 objects simultaneously.
| > Less than that and you have to make your "chain of command"
| > unnecessarily deep. More than that and you start spending more time
| > searching around or trying to remember what every one of these these
| > is about. (Don't remember where I saw it now; my wife is a
| > psychologist, that's most likely where :)).
| 
| It's not really new ;-), and is one of the basic properties of
| cognition (so basic it's part of any good Human Computer Interaction
| course). It is actually similar with numbers. Without tricks an
| average person can not remember more than 7 digits (without using
| tricks to remember things with a hint).

That is, 7 *unrelated* digits. If you ask someone (even a psych student)
to remember the sequence 123456789123456789 they probably won't have any
problems...

[ Yeah, ok, I'm just bitter because I have an HCI essay which covers
this kind of nonsense to write despite it being a computer *science*
course... ]

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Christopher Sachs]

Could you guys maybe throw in slimserver[1][2] under sound-streaming?
I have been trying to get this package into portage for frickin' six
months now!

Thanks a bundle,
Chris Sachs

[1] http://bugs.gentoo.org/show_bug.cgi?id=53524
[2] http://www.slimdevices.com/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Chris, I'm REALLY REALLY happy to see you do this. It's been a long time
coming.  I have some suggestions/concerns though, as follows:

Could not

> sound-encoders: anything that encodes/converts to mp3/ogg/whatever
> sound-sheet: programs that deal with sheet music notation/reading
> sound-editors: programs that edit audio files
> sound-rippers: programs that rip audio from a source
> sound-daemons: sound server programs go here
> sound-taggers: programs that deal with audio file tagging (ie. id3 tags)
> sound-synth: sound synthesizer programs
> sound-tools: programs that don't fall into the above categories.  I 
> consider this the "misc" section.
> sound-data: places for drum kits/sound presets/etc.
> sound-streaming
> sound-players
> sound-filtering
> sound-radio
> sound-drivers
> sound-DJ
Can we just not make sound-mixers and sound-DJ the same?  either way
you're mixing, no?
> sound-management
> sound-midi
> sound-mp3players
why can't these just go into sound-players?  Generally, the rule is 11
or more packages (I know it's not hard and fast, it's just been a
general rule of thumb) minimum to create a new category, and mp3-players
is just a specialised category from players.

> sound-mixers
> sound-dev
> sound-accessibility
I don't believe we need to divide the accessibility tools at this stage
of the game.  I think the sound-accessibility is just fine in
app-accessibility, no need to move them.

> sound-instruments
> sound-encoders
> sound-sheet
> sound-editors
> sound-rippers
> sound-daemons
> sound-data
> sound-taggers
> sound-synth
> sound-tools

There's a few in there that I think wouldn't need to be separated either
-- perhaps sound-daemons and sound-servers could also be combined? 
Also, maybe change sound-streaming to sound-streamers to be consistent
with the rest of your list?

Anyway, my overall suggestion is perhaps to refactor your list somewhat.

-- 
Seemant Kulleen
http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Christian Birchinger]

On Sun, Nov 07, 2004 at 05:00:08PM -0800, Seemant Kulleen wrote:
> > sound-DJ
> Can we just not make sound-mixers and sound-DJ the same?  either way
> you're mixing, no?

And if not, lowercase "sound-dj" would be better i guess.
Everything else seems to be lowercase.

Christian

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [LARGE MESSAGE] Media-sound reorganization!

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

On Monday 08 November 2004 02:00, Seemant Kulleen wrote:
> Anyway, my overall suggestion is perhaps to refactor your list somewhat.

Second that, while recategorization is good, the current list is a bit 
overdone.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]