Danek Duvall wrote: > It'd be easy enough to rename TRACKEDINBUGSTER to UPSTREAMDUP or something > else that was more generic. Similarly, the BugsterCR whiteboard keyword > could become UpstreamCR, and we could add a UpstreamCRDB keyword which > could take an argument either of a URL or a keyword such as "gnome" or > "mozilla" which could be expanded by the tracking software. > > That's all a simple extension of the current idea, which may be enough, at > least for now. > Yes that may be enough to do some useful things. Are there any objections or extensions to this approach?
> All components being tracked on defect.os.o should have some form of > version tag corresponding to the distro milestones they can be associated > with. (There's no multi-release as in Bugster, so when there are multiple > choices, someone will just have to make a decision. Ditto for multiple > architectures.) > > Danek > Yes, I find detailed revision tagging to be the biggest gap in existing bug tracking systems, including bugzilla. I like the concept of "bugseverywhere" where bugs were stored in the source code management system alongside the code. That way if you create a branch, all bugs existing at the branch point are automatically inherited to the new branch. If you close a bug in a branch, the "fixed" state is inherited by every rev downstream from that state change. We don't keep the bugs with the code, but we can provide tools which make it easier to associated a bug state change with the scm rev. _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
