Hi Carla,
Deployment will be done in phases. Phase-I will first synch up (first
time transfer) already files bugs/issues in BugTraq and Issuetracker.
Once that stablises, then we will have regular nightly transfers as part
of cron job
Here are some of the current features (& limitations) of the bridge
It runs as batch job (synchs up two systems in 24 hour period).
ChangeRequest refers to a bug filed in internal BugTraq system.
Issues Transferred into BugTraq will have following appearance
* Short Description :
o <IT XXX> ...
+ IT XXX denotes. IssueTracker, followed by 3 digit
Issue number
* SubmittedBy: glassfish-bugbridge_at_sun.com
* BugTraq User: GLASSFISHBB
* Hook1 field ="issue-tracker"
* Hook2 field=:"actual issuetracker number"
ChangeRequest transferred over to IssueTracker will have following
appearance
* <BTXXXXXX> ....
o BTXXXXXXX denotes BugTraq, followed by 6 digit change
request number so that people who have access to internal BugTraq system
can take a look at it.
* ReportedBy: gfbugbridge
* gfbugbridge is a separate user id for java.net under which this
bridge is run.
* keyword: glassfish-bugbridge
Business Rules for Mapping IssueTracker and ChangeRequest
* Bugs/Issues are automatically assigned engineers based on
engineer/categories mappings. Currently, only sun engineers and their
java.net user id's are mapped, but if it were to change later on to have
some external user owing a bug category., then it can be changed simply
by changing properties file
* If non conformant subcategory exists, then default responsible
engineer is glassfish-bugbridge_at_sun.com or gfbugbridge
* Exclude private bugs by putting in hook9 field "nojdc" which means
that "no java developer connection.
* Priorities are mapped as is.
o Issuetracker priority and Bugtraq priorities are same
o BugTraq Severity is currently same as original filed
IssueTracker's priority.
* Synch up currently works in "broadcast mode" . If a original
issue/bugtraq changerequest is updated, then that corresponding state is
propagated to bridged changerequests/issuetracker.
* Fixing code in bridge which will allow "back propagation" also,
which means that, if bridged changerequest/issuetracker is updated then
original filed issue/changerequest is updated as well.
* ChangeRequests/Issue can be upgraded or downgraded , however in
case of collision (same bug is downgraded in bugtraq, but upgraded in
issuetracker,) then bugtraq state is determined to be final as this is
not a real time system
* Currently corresponding H/w and Operating Systems are "All" for
IssueTracker and "generic" for bugtraq. A Detailed mapping of hardware
and operating systems between issuetracker and bugtraq is being worked on.
Known Limitations
* Synch up currently works in "broadcast mode" . If a original
issue/bugtraq changerequest is updated, then that corresponding state is
propagated to bridged changerequests/issuetracker.
* Fixing code in bridge which will allow "back propagation" also,
which means that, if bridged changerequest/issuetracker then original
filed issue/changerequest is also updated
* Attachments are not carried over due to a bug in internal
webservices API, so only names will be displayed
* Create SubCR for multiple releases for issues transferred in
bugster through bugbridge.
Carla Mott wrote:
> Hi Deepa,
>
> I hear that the bug bridge is ready for deployment. Do you have a
> timeline when that will happen? Will it be a phased approach?
>
> We need to have discussions so
> that users will know to expect to see alot more bugs in issue tracker
> all of a sudden if that is in fact true. Any limitations on the bug
> bridge
> when it mirrors bugs back and forth?
> Please provide more information so we know what to expect.
> Thanks,
> Carla
>
> Jerome Dochez wrote:
>
>>
>> right, so the bug bride will help. All this bugs should be transfered
>> in Issue Tracker and we can then use a specific Issue Tracker query.
>> The bug bridge is ready so I think we should start experimenting that
>> solution and use IT facilities. I talked about it with Carla
>> yesterday and she said she would contact Deepah about the bug bridge.
>>
>> Jerome
>>
>> Eduardo Pelegri-Llopart wrote:
>>
>>> I agree. I think we should put it somewhere in
>>> glassfish.dev.java.net... Amy and/or Carla, could you help?
>>>
>>> - eduard/o
>>>
>>> vince kraemer wrote:
>>>
>>>> I just tried to read Jerome's message, using the archive reader...
>>>> It is very hard to read the table of proposed fixes.
>>>>
>>>> See
>>>> https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=1261
>>>>
>>>> I assume that a number of people will want a central reference that
>>>> is readable after they accidentally delete the e-mail message...
>>>> It looks like the mailing list archive will not "do".
>>>>
>>>> vbk
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>