On Sun, 04 Feb 2007 15:19:17 +0100 Benjamin Mesing <[EMAIL PROTECTED]> 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.
pgpSbifAAVpu5.pgp
Description: PGP signature
_______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
