Versioned tag information

[Benjamin Mesing]

Hello,


> > > > 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.
> 
> Can you please give an example scenario, and explain exactly *in which*
> versions Tag-Set: and Tags-Diff: are used?

Scenario 1 usage of Tag-Set
----------------------------
Package firefox 1.3 tagged "use::browsing" "works-with::html" becomes a
dummy package in 2.0.
So the control field is set to 
        Tag-Set: role::dummy
If someone adds a tag  "web::browser" to version 1.3, this tag will not
be set for 2.0


Scenario 2 usage of Tag-Diff
----------------------------
Package packagesearch is tagged "uitoolkit::qt", "use::searching" in
version 1.3.
With the release of version 2.0 packagesearch gains the ability to
install packages, so it can be considered a full package-management
tool.
The Control-Field for 2.0 is
        Tag-Diff: +use::package-management

If someone adds a tag  "implemented-in::c++" to version 1.3, this tag
will also be set for 2.0.


> > 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?

Because in my opinion the flexible approach is superior to the static
one. That everything else is done one way, does not necessarily mean,
that it is the best way of doing it.
I do believe, that we will get better results with the community driven
tagging approach as opposed to the maintainer centric one (since tag
information is non-critical information). Please see my earlier posts
for my reasoning behind this opinion.
Especially we have a very long period ahead, where the tagging
information needs to be completed (among other reasons, because the
vocabulary is not yet stable).



> > 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.

I disagree. We can't change the packages after a release, since the
risks are to big -- the software might break. But tagging information is
much less critical, and thus could benefit from further improvement.


> 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).

Security updates are just that, security updates. Perhaps some kind of
volatile support might work.


Regards Ben