You can bookmark the URL that was generated by your search request and
reuse it.
Am 04.07.2012 15:28, schrieb Zieris, Franz:
> Dear Saros developers,
>
> one issue has been running in my mind since I saw it for the first time. I'm
> talking of the multiple trackers we own in our Sourceforge space. Currently
> we're talking about no less than four trackers, each with a slightly
> different purpose: Bugs, Documentation Issues, Feature Requests and
> Refactoring Requests.
>
> I didn't bring up this topic yet, because although I'm quite unhappy with
> this situation on a conceptual level, I did not see any huge practical
> drawbacks.
>
> But: Yesterday Stefan "moved" a tracker artifact from "Bugs" to "Feature
> Requests" (from [1] to [2]). This clearly demonstrated several disadvantages
> (this is not against you, Stefan :):
>
> * The fields "Assigned to", "Category", and "Group" and the visibility of
> the "Resolution" field are maintained separately for each tracker. That means
> that e.g. every new project member needs to be added to all trackers
> manually, to be selectable as the artifact's assignee.
> * The field "Tracker" is mutable, which allows a migration from one tracker
> to another. But since the value ranges of the several fields are different
> for each tracker, data loss may result. Additionally I fear that this changes
> the URL of the item as well, because the Tracker id ("atid") is part of the
> URL. The alternative way of a copy-paste "migration" (as Stefan did) is not a
> real alternative: There is no way of backtracking, comments are lost in the
> artifact, etc.
>
>
> General problems with more than one tracking system:
>
> * Developers don't have a simple, single access point to gain the
> information they need: e.g. "What are my open tasks?" -- One can use the
> "Advanced Search" and select multiple trackers, but since I see no
> possibility to save these queries (as it is possible in Trac) this is only a
> workaround and not efficient.
>
>
> My proposal:
>
> * Only use one single tracker.
> * There is no need for Documentation Issues, Feature Requests and
> Refactoring Requests to be heavily sub-categorized. Therefor a single new
> Category for each former Tracker ("Documentation", "Feature Request",
> "Refactoring Request") should be sufficient.
> * I know: The migration of the open tasks is a stupid, but feasible work.
>
> Any comments or objections?
>
> Franz
>
>
> Links:
> [1]
> https://sourceforge.net/tracker/?func=detail&atid=843359&aid=3514927&group_id=167540
> [2]
> https://sourceforge.net/tracker/?func=detail&atid=843362&aid=3539934&group_id=167540
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Dpp-devel mailing list
> Dpp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dpp-devel mailing list
Dpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
