[opensuse-buildservice] Proposal for project in root namespace: console
I suggest creating project "console" for programs not requiring X. May be split into console:whatever (probably later, after acquiring enough packages). Best regrads Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Petr Cerny wrote:
I suggest creating project "console" for programs not requiring X. May be split into console:whatever (probably later, after acquiring enough packages).
Not sure it's a good idea. Just an example: mcabber. It's a Jabber client that runs in the console. Where to put it, "server:messaging" (ok, "server:" isn't great, but that's the only place I could find for Jabber stuff), or "console" ? IMO it would be preferable to organize packages by purpose instead of by environment (especially X or console). There's already a huge list of repos -- if we don't make it as distinct as possible, people won't know where to find or expect stuff. Well, just my 2 cents. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGgC7tr3NMWliFcXcRAj5fAJ9hI7gLSSqcV70bjoDDtH+u5eCUsgCcCOAH 6pm/ubXwt4hwbj/lUgGccWs= =jbIw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 25 June 2007 23:09, Pascal Bleser wrote:
IMO it would be preferable to organize packages by purpose instead of by environment (especially X or console). There's already a huge list of repos -- if we don't make it as distinct as possible, people won't know where to find or expect stuff.
The question is what is a good criteria for organizing packages namespace-wise. My feeling is that dependencies would be a good criteria. This would mean that grouping packages which don't have X dependencies in a project or namespace actually would make sense. For developers and packagers I think this could also be helpful when finding stuff. For end users the problem of finding software is more complex and has a lot of different aspects. I'm not sure a simple namespace hierarchy is helping here a lot, regardless if we organizer by purpose or by dependencies. To create a good user experience we have to rely on more sophisticated mechanisms anyway, like a good search, tags, ratings, etc. Just a thought. -- Cornelius Schumacher <cschum@suse.de> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Cornelius Schumacher wrote:
On Monday 25 June 2007 23:09, Pascal Bleser wrote:
IMO it would be preferable to organize packages by purpose instead of by environment (especially X or console). There's already a huge list of repos -- if we don't make it as distinct as possible, people won't know where to find or expect stuff.
The question is what is a good criteria for organizing packages namespace-wise. My feeling is that dependencies would be a good criteria. This would mean that grouping packages which don't have X dependencies in a project or namespace actually would make sense. For developers and packagers I think this could also be helpful when finding stuff.
The fine thing with BS is, that you can link packages into projects. So there is no problem having it in more projects and maintaining only once (in home project for example). This way "mcabber" (mentioned by Pascal Bleser) can be in network:clients and desktop:messaging and console:net. I think there's nothing wrong with it. Actually, it would be in all places where it would be expected by normal user. :) OTOH such "multi-trunked" hierarchy (I would call it "shrubbery") might be considered partial duplication of Tags.
For end users the problem of finding software is more complex and has a lot of different aspects. I'm not sure a simple namespace hierarchy is helping here a lot, regardless if we organizer by purpose or by dependencies. To create a good user experience we have to rely on more sophisticated mechanisms anyway, like a good search, tags, ratings, etc.
Tags and ratings are implemented. Question is, whether some sophisticated search is available for those not logged in. Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Petr Cerny wrote:
The fine thing with BS is, that you can link packages into projects. So there is no problem having it in more projects and maintaining only once (in home project for example). This way "mcabber" (mentioned by Pascal Bleser) can be in network:clients and desktop:messaging and console:net. I think there's nothing wrong with it.
There is: It's a waste of bandwitdh and space on mirrors. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Michal Marek wrote:
Petr Cerny wrote:
The fine thing with BS is, that you can link packages into projects. So there is no problem having it in more projects and maintaining only once (in home project for example). This way "mcabber" (mentioned by Pascal Bleser) can be in network:clients and desktop:messaging and console:net. I think there's nothing wrong with it.
There is: It's a waste of bandwitdh and space on mirrors.
Than change in BS is necessary. Either "link" should really do link or it should be renamed to avoid confusion. Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 26 June 2007 13:12:40 wrote Petr Cerny:
Michal Marek wrote:
Petr Cerny wrote:
The fine thing with BS is, that you can link packages into projects. So there is no problem having it in more projects and maintaining only once (in home project for example). This way "mcabber" (mentioned by Pascal Bleser) can be in network:clients and desktop:messaging and console:net. I think there's nothing wrong with it.
There is: It's a waste of bandwitdh and space on mirrors.
Than change in BS is necessary. Either "link" should really do link or it should be renamed to avoid confusion.
it is a source link and therfore the naming is right, but it results in multiple binary packages ... -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Adrian Schröter wrote:
On Tuesday 26 June 2007 13:12:40 wrote Petr Cerny:
Michal Marek wrote:
Petr Cerny wrote:
The fine thing with BS is, that you can link packages into projects. So there is no problem having it in more projects and maintaining only once (in home project for example). This way "mcabber" (mentioned by Pascal Bleser) can be in network:clients and desktop:messaging and console:net. I think there's nothing wrong with it. There is: It's a waste of bandwitdh and space on mirrors. Than change in BS is necessary. Either "link" should really do link or it should be renamed to avoid confusion.
it is a source link and therfore the naming is right, but it results in multiple binary packages ...
OK, I see. Is the problem - creating package for the sake of logical assignment into projects - solvable via "aggregate"? Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2007-06-26 14:04:39 +0200, Petr Cerny wrote:
OK, I see. Is the problem - creating package for the sake of logical assignment into projects - solvable via "aggregate"?
aggregate has the same problems on the mirror side as linked packages. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Marcus Rueckert wrote:
On 2007-06-26 14:04:39 +0200, Petr Cerny wrote:
OK, I see. Is the problem - creating package for the sake of logical assignment into projects - solvable via "aggregate"?
aggregate has the same problems on the mirror side as linked packages.
Is it then possible to create some "foolink" which would have the properties of "ln -s" which could be used for sorting packages into different projects/groups? Or some search engine working with software.opensuse.org/download , capable of using Tags from BS? Otherwise people without BS account willo have hard times finding packages (that is if we want them to install packages without invitation from maintainer). Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue, 26 Jun 2007, Petr Cerny wrote:
Marcus Rueckert wrote:
On 2007-06-26 14:04:39 +0200, Petr Cerny wrote:
OK, I see. Is the problem - creating package for the sake of logical assignment into projects - solvable via "aggregate"?
aggregate has the same problems on the mirror side as linked packages.
Is it then possible to create some "foolink" which would have the properties of "ln -s" which could be used for sorting packages into different projects/groups? Or some search engine working with software.opensuse.org/download , capable of using Tags from BS? Otherwise people without BS account willo have hard times finding packages (that is if we want them to install packages without invitation from maintainer).
I also would like to have a type of link, which acts as a softlink in the download hierarchy (including the updates of the related meta files). Thought I do not know how to handle packages which have less repositories in their base project, than in the linking destination project. Another disadvantage of links beside space and bandwidth is confusion. Each of the packages has different revisions. For a user it's confusing to know which of the packages is the one to take. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Dirk Stoecker wrote:
Another disadvantage of links beside space and bandwidth is confusion. Each of the packages has different revisions. For a user it's confusing to know which of the packages is the one to take.
IMO this is only a problem if links are used where aggregates or project stacking would be more suitable. If you use links to create modified packages (either directly patched or built in a different environment), it's not that confusing that different packages have different release numbers. Michal --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue 26 Jun 2007, Pascal Bleser wrote:
Petr Cerny wrote:
I suggest creating project "console" for programs not requiring X. May be split into console:whatever (probably later, after acquiring enough packages).
Not sure it's a good idea.
Just an example: mcabber. It's a Jabber client that runs in the console.
Where to put it, "server:messaging" (ok, "server:" isn't great, but that's the only place I could find for Jabber stuff), or "console" ?
This is actually something I have been meaning to bring up. When the Build Service was first launched I started the following projects (whos names fit the packages I originally put in them): server:monitoring server:telephony server:messaging network:aaa Now, a year later, network:aaa (which is the smallest of them) is the only one that has a name that matches the collection of packages it contains. server:monitoring also contains a bunch of network monitoring tools. server:telephony contains a bunch of telephony clients as well as related libraries. server:messaging also contains a couple of messaging clients. The question is should we: * split of a client: namespage (not my preference..) * turn things around and create telephony:server and telephony:client etc * leave things are they are... Suggestions? Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On 2007-06-26 22:13:18 +0300, Peter Nixon wrote:
server:monitoring server:telephony server:messaging
s/server:/network:/ which will be started soon. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tue 26 Jun 2007, Marcus Rueckert wrote:
On 2007-06-26 22:13:18 +0300, Peter Nixon wrote:
server:monitoring server:telephony server:messaging
s/server:/network:/
which will be started soon.
That works pretty well for server:messaging as "messaging" these days usually implies a network component. On the other hand server:monitoring in addition to the network monitoring stuff also currently contains the following non-network monitoring tools (maybe they should move elsewhere): dstat logdigest logwatch atop mailgraph server:telephony is even hairier. Apart from the usual raft of client and server VoIP programs it currently contains audio (and soon probably video) compression codecs, CDR billing and rating tools, telephony hardware drivers, and a bunch on protocol libraries that range in usage from (Vo)IP to GSM, 3g and traditional telephony including analog and ISDN telephone trunks.... Thats not including the aggregated packages which include RADIUS, XML and console libs... I already broke sipX off into its own project (server:telephony:sipx which contains 15 packages by itself) but I thinking that we are rapidly approaching the need for a top level "telephony:" namespace.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Op Tuesday 26 June 2007 22:57:18 schreef Peter Nixon:
server:telephony is even hairier. Apart from the usual raft of client and server VoIP programs it currently contains audio (and soon probably video) compression codecs, CDR billing and rating tools, telephony hardware
What is the CDR billing tool?
I already broke sipX off into its own project (server:telephony:sipx which contains 15 packages by itself) but I thinking that we are rapidly approaching the need for a top level "telephony:" namespace..
That would be good indeed! -- Richard Bos We are borrowing the world of our children, It is not inherited from our parents. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed 27 Jun 2007, Richard Bos wrote:
Op Tuesday 26 June 2007 22:57:18 schreef Peter Nixon:
server:telephony is even hairier. Apart from the usual raft of client and server VoIP programs it currently contains audio (and soon probably video) compression codecs, CDR billing and rating tools, telephony hardware
What is the CDR billing tool?
cdrtool :-) There are PLENTY more, but I havent gotten around to adding them yet. They could all probably live in a telephony:billing or telephony:rating project for example. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed 27 Jun 2007, Richard Bos wrote:
Op Tuesday 26 June 2007 22:57:18 schreef Peter Nixon:
server:telephony is even hairier. Apart from the usual raft of client and server VoIP programs it currently contains audio (and soon probably video) compression codecs, CDR billing and rating tools, telephony hardware
What is the CDR billing tool?
I already broke sipX off into its own project (server:telephony:sipx which contains 15 packages by itself) but I thinking that we are rapidly approaching the need for a top level "telephony:" namespace..
That would be good indeed!
Does anyone else have any comments regarding creating a top level "telephony" namespace? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (9)
-
Adrian Schröter -
Cornelius Schumacher -
Dirk Stoecker -
Marcus Rueckert -
Michal Marek -
Pascal Bleser -
Peter Nixon -
Petr Cerny -
Richard Bos