[Debtags-devel] Re: Recent progress

[Hervé Eychenne]

On Mon, Feb 28, 2005 at 06:49:05PM -0800, Erich Schubert wrote:

 Hi,

> > We need it _anyway_. :-)

> No we don't. We do not need to keep track which tags have been
> introduced since which package was carefully tagged the last time.
> Partly because packages will never be completely/carefully tagged, and
> no one will bother to check the packages frequently.

If we don't implement timestamping, it becomes impossible to track
which tags are introduced after a complete review (of a package).
So it becomes all the more hard for the {maintainers who would be
willing to do so} to maintain the tags for their packages.
And it becomes impossible to be sure that a package has been carefully
tagged.
That's a real pity/mess.

We both agree that each and every package will probably never be carefully
tagged.
But at least I want to help each person who wants to take good care of some
packages.

I don't adhere to your "nothing will ever be perfect as a whole so why
bother supporting the people who want to do things well" strategy.

> It will happen like someone noticing that a package is missing tags
> and then telling the maintainer "hey, please fix your tags"
> No need for versioning for that.

Too dispersed and hypothetic strategy, I think.

> > Without timestamps it would still require a whole big check just befo=
re
> > every release.

> Yes. It will always.

Not with an incremental revison.

> Just having version tracking will not make people care more.

It will very much ease the task for the people who care.
Not having timestamps would encourage no one, and discourage
quite a few (to begin with me).

> > Either Debian continues with its current (awfully long) release cycle
> > and that's way too long to reflect the potential evolution of tags,
> > or it gets a reasonable 9 months cycle and a complete recheck would
> > be required much too often.

> There is nothing wrong with debtags giving out new vocabularies every
> couple of months. But we should try to keep this low if we have a
> slight hope of maintainers then actually updating the tags for their
> packages.

We perfectly agree on that.

> > Here is my experience: the last few times I've been looking for tools
> > doing some given kind of work, I couldn't even find any tag represent=
ing
> > the precise kind of operation I needed.

> So what is the point? I did not claim that our current vocabulary was
> ready to release, not at all.

With the current strategy, it never will be, that's the point. :-)

> > - new technologies or uses appear regularly

> Not really. Every now and then. And then its *easy* to add the tags
> for the new technologies, because only few packages will use it, won't
> they?

We agree.

> > If we would give full exposure to the tagging system today, with full
> > maintainer attention, I'm sure the taglist size would double in a few
> > months.  Yes, a small team cannot think about everything.

> Yes, but then we might have adopted a bad choice of base facets, for ex=
ample.
> As I wrote earlier, I'm not completely happy with the current set.

... and will not be able to find the perfect set alone, or even with
a small team of motivated people like us.

> > Imagine the vocabulary would be frozen for a certain time when people
> > really start to tag packages. I can already tell you what will happen.

> So what, Debian can handle this with packages as well. There is
> nothing wrong with having two trees.

I was not aware that you were proposing 2 different trees... Ok...

> But if we make the vocabulary a moving target

The vocabulary is not a target. :-) Ok, forget it...

> we will *never* reach some satisfying point. Especially
> if everybody uses a different version (!)
> That is the whole point of "releasing".

No one would be using a different version. There would be only one
central repository, like today. And you could not make changes without
synchronizing with the central repository.

> > One day, the vocabulary would be officially updated, and those people

> > Yes, but that is not the most common addition scenario. I need a prog=
ram
> > to watch TV. Do we currently have a tag for that? No. I need a progra=
m
> > to make screen captures. Do we currently have a tag for that? No. I
> > need a program to do some calculation operations. Do we... ? No.
> > I need a program to help me manage my bookmarks. Do we... ? No.

> Well, this just shows that our tags are not well chosen yet.

I shall repeat again that I think that the tags won't be near to perfect
before long. And you certainly won't make it perfect by yourself.

> But I do not think we'll need a tag for bookmark management, for exampl=
e.

And in the name of what? If it can be useful, there is no reason not
to add such things (from my point of view).

> TV, okay. Screen captures maybe.
> We are *not* trying to make a complete map of all uses applications
> could have etc.

No??? Ok, here we are. The more complete it would be, the happier I
would be.

> Only what is useful for grouping them.

Now I see why our opinions so frequently differ... our goals are
apparently different. For me, the goal of tags is to be able to find which
program(s) can do the operation I want to achieve as quickly as possible,
for example.

If your goal is grouping for the sake of grouping... well... I'm
voiceless.
Do everyone reading this agree with Erich??

> More tags => more work => less adoption

Haha. So let's reduce tags to the very minimum. User utility reduced to
almost nothing, but developer adoption garanteed!
Sorry for being sarcastic.

> Isn't it like that already, that there are way to many tags,

That's your point of view.

> so noone has an overview which tags are appropriate

I have a very good overview of which tags are appropriate for the
software I created, believe me. And many other people would
(especially if existing tags would have a good description).

> or when a package maybe is completely tagged?

It would be very easy if timestamping was implemented: if you wanted, you
could review your package completely (from zero) once, and then only add
the tags you want among the list of new tags (those added after the last
complete review). Quick and efficient.

> > > I'm currently considering writing a new web tagging application tha=
t
> > > makes heavy use of the "new" javascript-xml-async-technologies (lik=
e
> > > gmail, maps.google.com etc.) - what do you think? I will only be ab=
le
> > > to do this for gecko-based browsers...
> > 
> > I think that might be funny for you to program and for us to play
> > with, but I certainly don't think that that's really important at

> Wasn't it you who complained that the web interface is bad?

I noted that IMHO the current web interface fails to work well for the
two things that matter:
- finding the package you want
- ensure complete tagging of a package

For the former, mainly because of the presentation (balanced view
between subgroups and list of packages). For the latter, because of
the lack of a form that would take directly to a package whose name is
known (simple), because of the lack of some management facilities such
as the impossibility of knowing if a package is carefully tagged
(would require timestamping as I described), and because of the
unprecise meaning of some existing tags (let's start by showing their
descriptions!).

None of those reasons would be solved by introducing
"javascript-xml-async-technologies". They could perfectly be solved
with pure HTML.

I mean, javascript-xml-async-technologies would be eventually cool, but
they are absolutely not a priority for me given the current lacks.
But I see you don't consider them lacks, and that you even seem
opposed to fix them(!), so... if I failed to convince you or anyone
else, I don't see the point in discussing too much and waste our
times.

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/