Announcement of new packagebrowser?

[Enrico Zini]

--TxukmIqg3MmZ0Kmh
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 30, 2003 at 10:44:59PM +0200, Erich Schubert wrote:

> doesn't affect others. But they might contribute more to our project
> this way. It might help promoting the subproject, which is a nice side
> effect. When we disagree on some tagging with them we can still ask them
> to move that tagging into a tag-diff file, that is easy.

Agreed.


> You could also just move them back to "not-yet-tagged". The difference
> between an untagged and a package with "broken" tags isn't too big.

I'd investigate in how a tag editor works before agreeing in that: it
might be that adding new tags from scratch and rewiewing tags already
partly added by someone turn out to be slightly different tasks, and
that someone would want to do one and not the other.

Or maybe not: that's why I say "I'd investigate".


> > 	Edit::not-yet-tagged
> > 	Edit::need-review
> > 	Edit::corner-case
> > 	Edit::need-discussion
> Hmm... i kind of dislike mixing this information with the other tags.
> You don't want to have a "corner-case" subcategory. ;)

Me too, I've always feared misuses of tags in this sense.

However, if those special tags are kept inside a given limited
environment and they do not leak into the real database that everyone
uses, there is no risk that I can see in using them.


> Still this makes it easier to search for such cases to discuss them.
> But after all this collaborative editing is just a temporary solution.

Yes, but we neither know for how long we will have this temporary
solution, nor if it will eventually turn out to be an optimal solution
that we didn't expect.

Since it's not a bad solution that we deprecate, there is no reason not
to improve it if we can.  And adding tags that introduce a form of
communication between editors can be an effortless addition that brings
important benefits.


> The "specialized" tag should IMHO be added to the regular vocabulary.
> Subprojects can introduce a new tag - kind of "highly-specialized" for
> their use. I'd prefer this to them removing the "specialized" tag in
> their patch files.

I can't see of a tag like "specialized" can be assigned in an objective
way: I consider every law-related stuff as "specialized" stuff, while a
lawyer can consider law-related stuff as "essential" and C++ compilers
as "specialized" indeed.

However, if you come out with some objective definition of
"specialized", I'd be more than happy to see that tag in the regular
vocabulary.


> > How about this:
> >  Desktop::Gnome
> > [snip]
> >  Desktop::Standalone
> >=20
> > And this:
> >  Toolkit::QT
> > [snip]
> >  Toolkit::Xlib

> I had been considering this before, but the problem is that Gnome isn't
> just a desktop environment using GTK, but it does contain real
> extensions to gtk. Nicer fileselectors, bonoboui and such.

I do not see the problem if we keep desktop suites and toolkits
separated: since those applications are not part of gnome, they won't
have the desktop::gnome tag; however, they would still be standalone
applications, and they can have the desktop::standalone tag.  They can
also have the toolkit::gtk tag, because they are indeed based on Gtk.


> OTOH I was thinking if we need to make the difference between gnome and
> gtk actually visible in the package browser - most user won't care much.

Gnome, KDE, Gnustep and others, are desktop suites.  Outside of the
union of all such desktop suites there are standalone applications.

A quality that distinguishes those standalone applications is the
toolkit they use, and it can be interesting because it generally
involves peculiar differences in terms of integration with other
applications or consistency of user interfaces.  I might prefer a Gtk or
QT text editor to an Athena-based one, for example, while if I had to
use a 486 machine, I'd probably prefer a rough Athena-based text editor
since it's likely to be much lighter than a Gtk or QT alternative.

Indeed, we can design better sets of tags to identify useful
cathegorizations for these goals, but at the moment we have this one, so
why not using it?


> OTTH there are packages like gconf that don't have an UI, but that
> belong to Gnome (so they are real Desktop-Environment issues)
> That is why desktop::gnome cannot imply ui::gtk. :-(

Good point: I agree that gnome won't have to explicitly imply gtk, and
that kde won't have to explicitly imply qt, and so the other desktop
suites, since a commandline helper tool can be very well part of a
desktop suite.


> We could also need some "ui::graphical" (or ui::x11?) tag that allows to
> remove text mode programs from the selection.

What about an explicit ui::text or ui::term instead?


> There are nice perl modules for such things. Cache::FileCache

Good, thanks!  I'll have a look at it, since I'm using similar things
also for another project I'm working on.


Bye,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

--TxukmIqg3MmZ0Kmh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sRtv9LSwzHl+v6sRAiE6AJ9Je3HBAh+4OY9hhdt/z1ywfxNRvQCdFK8r
zfGxDSd4F25kJjWG6cpskYw=
=YA42
-----END PGP SIGNATURE-----

--TxukmIqg3MmZ0Kmh--