Re: re-categorization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary, first of all thank you very much for the time you took into creating all 
this categories and writtign this mail and I can say that I totally agree 
with your point of view!
I like to have the categories of the applications as closer as posible to the 
K menu, so, like SuSE, we'll be able to create a wanna install K menu based 
on thos categories that that the user could use to install aplications.
Thank you very much!

On Saturday 20 March 2004 14:46, Gary L Greene Jr wrote:
> On Saturday 20 March 2004 09:46 am, bero wrote:
> > On Fri, 19 Mar 2004, Pupeno wrote:
> > > As you may know I wanted to work on the re-categorization of ark rpms
> > > but changing all the rpms will mean people will have to re-download
> > > anything and in a dial-up that's bad... so, I've come with the idea of
> > > doing the re-categorization but don't change version, so people won't
> > > re-download but the recategorization will be done and in the next build
> > > of a package, the re-categorization will be active.
> >
> > Not a very good idea, because apt and the checksum apps don't like that
> > at all.
> > Let's just do the re-categorization step by step -- change it when we're
> > changing something in the package anyway (and people will have to
> > download the updated package anyway).
> >
> > Since we'll be updating to gcc 3.4 soonish (it entered deep freeze ("open
> > for bug fixes for regressions only") 2 weeks ago), we'll have to rebuild
> > pretty much every package soon anyway.
> >
> > No reason not to start recategorizing packages right away though -- we
> > should discuss the right categories as soon as possible.
> >
> > LLaP
> > bero
>
> I've been looking through the top level categories that Pupeno is
> advocating (Application, Library, Text Application, and System) and I'm
> thinking that they may be too few overall. What about documentation, like
> books or how-tos? Does it go in Application? How about development tools?
> Surely we shouldn't lump them in the other categories.... Due to this I'm
> in favor of the following top level categories:
>
> 	Applications		   // Contains all non-system GUI applications
> 	Command Line Applications  // Contains all non-system CLI applications
> 	Development		   // All devopment tools and -devel packages, this includes
> 				   //    GCC.
> 	Help			   // All books, how-tos, man pages, etc.
> 	Internationalization	   // All language specific packages go here.
> 	Libraries		   // All non-system libraries go here.
> 	System			   // All System level applications, libraries, stuff goes here.
> 				   //    This includes X11 and kdebase/libs
>
> Under Applications I am in favor of dividing the top level into the
> following sub-categories:
>
> 	Editors
> 	Edutanment
> 	Games
> 	Internet
> 	Multimedia/Graphics
> 	Multimedia/Sound
> 	Multimedia/Video
> 	Office
> 	Scientific
> 	Toys
>
> As you can see, I tried to mirror the current K-Menu closely with the sub
> categories here. In the Command Line Applications section, I propose the
> following sub-categories:
>
> 	Editors
> 	Multimedia/Graphics
> 	Multimedia/Sound
> 	Multimedia/Video
> 	Network Client
> 	Network Server
> 	Scientific
> 	Toys
>
> Under Libraries, we may want to favor leaving all of them UN-categorized,
> since these should only be selected by the Requires of an Application or
> Command Line Application. Now on to Development. I see a split of the
> following:
>
> 	Ada
> 	C
> 	C++
> 	C#
> 	F77
> 	Java
> 	Perl
> 	Python
> 	Tools
>
> This seperates all computer languages into their own category. Also, any
> library's -devel package go in the appropriate language category. Next in
> our top-level categories, we come to Help. This needs split up due to the
> high number of packages in here, making traversal a pain. I propose the
> following sub-categories:
>
> 	Books
> 	Howtos
> 	Info
> 	Manuals
>
> These categories are intended to help the user find the documentation they
> need fast. Now on to the longest named category: Internationalization. I
> would suggest that we split this up based on the natural language that the
> package is intended to allow ark to display. I won't attempt to list them
> here since I know that Ark has an absolutely MASSIVE number of i18n support
> packages (however, this area could always stand to expand). Finally we come
> to System. By default the user shouldn't need to look to deeply here, but
> there are the few out there that LIKE to tinker (we need to support our
> developer base too...) With this in mind, I propose the following
> sub-categories:
>
> 	Applications
> 	Drivers
> 	Kernel
> 	Libraries
> 	Servers
> 	User Interface
>
> As you can see, the top-level and subs that I propose are fairly easy to
> navigate, and are still nicely categorized for us people that are
> organization nuts :)

- -- 
Pupeno: [email protected]
http://www.pupeno.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAXcv0tCepaMf3unIRAl8AAJ0YUaNIWT4nvMt1rvL9UvlyJ0bbpwCdEGqX
5cb9cCxL3KmEPV5PltK9u7M=
=Bh6B
-----END PGP SIGNATURE-----