-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Schröter wrote:
On Wednesday 17 October 2007 18:53:41 wrote Pascal Bleser: [...]
One task that is notably missing is the reorganization of the repositories. Right now it's seriously starting to become a mess, I'm afraid :\ [...] Note that it also means discussing and finding guidelines about a few things, most notably: repositories and packages by desktop environment (KDE:*, GNOME:*) or by task (client:messaging, multimedia:photo) ? Or some here and some there, as it is now ? (which is quite suboptimal IMO)
Please keep in mind that the organisation of the projects depends on the wanted build enviroment. Packages/versions which can be reused in the build enviroment or not. Additionaly it does also define the group of people with write access to it.
Not sure the build environment is really a criterion in the current grouping of packages into projects as of now, at least not for most of them. I mean, one of the real questions in terms of organization of the projects and packages is whether to group by "desktop environment" or by "purpose" -- e.g. put kftpgrabber into "KDE:something" or in "filesharing" ?. The build environment is hardly a reason to put kftpgrabber into KDE:Community, as it's pretty much the same target build repositories everywhere (openSUSE_10.3, openSUSE_Factory, etc...), with the notable exception of the repos with the latest Apache (e.g. for Subversion). To me, the choice of where to host a package like kftpgrabber (or kbackup or keep, could be in Archiving:Backup as well) is arbitrary and non-deterministic as of now. Is the user who wants to add access to packages asking for "a file transfer client for KDE" or "a file transfer client" ? Of course, we could also have them aggregated into both. Just that it means more files to rsync for the mirrors. Except if pure repository metadata aggregation is feasible and can be implemented. And write access, dunno. Is it really important that a person has access to server:foo but not to client:foo ? Are some categories more "critical" than others wrt that ? Hardly.
It is NOT intended to setup the projects in a away to make it easier to find packages, this needs to be done via different techniques like the software.o.o/search interface.
It definitely needs to be done then, because currently it's quite difficult for a somewhat less experienced user to find his way into the tangle (dare I say "mess" ;)) of existing repositories. But the Build Service roadmap contains half of the items on the Software Portal roadmap anyway so I guess it will be implemented at some point. Why work together one someone else's ideas, right.
As an example, gimp is in GNOME:STABLE, gqview is in multimedia:photo; konversation is in KDE:KDE3, irssi in server:messaging. Oh, yeah, and that's one of my pet peeves (Marcus knows about it ;)): there are some obvious repositories/categories that are missing: - client:messaging - client:mail - client:ftp - system:utilities ... (or move *:irc/* into *:messaging ? merge filesharing and client:ftp as filetransfer ? etc...)
hm, maybe all client:* projects can be put into one ? Hm they have disappeared already ;)
Why put them into one ? Then we can drop most of the subcategories for
server:* as well, it's exactly the same situation.
As said, it's arbitrary and target repository grouping has nothing to do
with the vast majority of the packages as far as I can see, as most are
just built against the standard repositories.
So what's the substance of your reply, keep it as is ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\