On 06/01/17 15:01, Rich Freeman wrote: > On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric wrote: >> If packages had a field called "BUGS=" it could contain an array of >> bugs a package is known to contain, but can be conditionally avoided if >> you're careful. >> >> Packages with non-empty BUGS= fields would be treated as hard-masked >> for the purpose of repoman checks, and so packages that depend on >> specific version ranges of packages with BUGS= fields are invalid, >> and need their own BUGS= fields. >> > So, while I'm not sure if this is the best way to go about it, I think > what it does point to is there being possible benefit in creating a > closer link between our repository and bug trackers. > > We've seen this come up in managing stable requests as well (having > users be able to vote on things, having automated testing, etc). > > With the recent stable changes we have bugs being tagged with "atoms." > With your proposal we have ebuilds being tagged with bugs. > > I can see benefits to having a single way to associate bugs and > ebuilds, and making those associations available to bug trackers and > package managers. > > I think the question is: > 1. What is the best way to go about this? > 2. Is anybody actually going to make use of this? > > The intended use cases in #2 probably will influence #1. However, it > doesn't make sense to have multiple ways of doing these associations, > because bugzilla doesn't know anything about the repo, and portage > doesn't know anything about bugzilla. Having one place to store the > associations and tools to make that information accessible elsewhere > makes more sense. > #gentoo-grumpy :) o/ leio !