Mark J. Nelson wrote:
> Brian Nitz wrote:
>> 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?
>
> It would seem generally more useful to expand the cross referencing
> capability generically. Ie anyplace that a "bugid" is referenced, use
> a tuple consisting of { dts, key }. Then "duplicate of" or "tracked
> in" (or "depends on" or "blocks") would work with any other system.
>
> That's probably a prohibitive undertaking, but it would certainly be
> useful for Bugster AND for upstream defect tracking systems.
>
> --Mark
>
I already have dts and key within the multiple bug database bugmanager
but it would be nice to have the links to the "duplicate", "blocks",
"depends on" or "tracked in" bug live within a bug's native database.
That might not be practical without convincing a lot of organizations to
accept a patch to their bugster, or hacking the tuple into one of the
existing fields.
I hate to complicate things further, but in the truely general case,
aren't some of these one to many or many-to-many relationships?
>
>>> 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
>
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
