Versioned tag information

[Andrea Bolognani]

On Sun, 04 Feb 2007 15:19:17 +0100
Benjamin Mesing <bensmail at gmx.net> wrote:

> > > The idea is somewhat borrowed from versioned bugs. If a tag is added to
> > > a package, the tag is submitted together with the version information
> > > for the package.
> >
> > This is something you already get for free with tags declared in the control
> > file.
>
> Not exactly. Tags declared in the control file are missing the part,
> that information is propagated from older versions to newer ones.
>
> Additionally we could do vocabulary rearrangements (like renames) simply
> by adding the rename to the central repository.

To propagate some tags from an older version of a package to a newer one, you
just need to leave that tags in the control file.

> > > Finally the maintainer could do the tagging using two fields in the
> > > control file. One for defining diffs, and one for totally redefining the
> > > whole tag-set.
> > >         Tags-Diff: +tag1, +tag2, -tag3
> > > and
> > >         Tag-Set: tag1, tag2, tag3, tag4, tag5
> >
> > Why the need to have two different fields?
> > Wouldn't be a single Tags: field be enough?
>
> Not with the approach I was suggesting.
> The Tags-Diff: field defines a diff of tagging, regardless of whatever
> the tag set was before is. So if some package has gained a feature in a
> version I would add the appropriate tag to the package using [+tag].
> This way, if someone tags an older version with a different tag, the tag
> will be propageted to the newer version.
> The Tag-Set: field sets a new starting point for subsequent diffs.

I don't think I'm getting this.
Can you please give an example scenario, and explain exactly *in which*
versions Tag-Set: and Tags-Diff: are used?

> Basically it all comes down to the question: Who is doing the tagging?
> I used to be in favour of the "tagging is soly the responsibility of the
> maintainer" approach. But after the arguments presented I am not so sure
> any more.
> Look at wikis for example, usually they are more up-to-date than
> traditional webpages. Especially if the web-site maintainer is
> unresponsive. For Debian, were we have more than a thousand maintainers,
> there are usually some ones MIA. Control fields are very static, a tag
> rename could take ages to ripple through the archive.

The same thing applies for anything related to the mainteinance of a package,
from fixing bugs to keep it up-to-date.

Why should tags be treated differently?

> Also, once a
> Debian distribution is release, there is no way to change the tagging
> information. IMO leaving the possibility to fix the tagging open, would
> be benefitial.

Once a release is made, the tag set for that release should be frozen anyway.
Just like any other thing. Tags could be updated for point releases, of
course, or via security-updates (I'm not sure how security-updates work, so
I could be saying nonsense).

--
KiyuKo <eof AT kiyuko DOT org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20070205/ca52954d/attachment.pgp