https://www.mediawiki.org/wiki/Phabricator/Help states that projects supersede components, products, keywords; it also seems to imply tracking bugs are superseded as well. But it also says that creating a project requires advanced permissions. What process are we supposed to use for tracking bugs?
Description
Description
Details
Details
- Reference
- fl500
Related Objects
Related Objects
Event Timeline
Comment Actions
qgil wrote on 2014-07-24 10:59:51 (UTC)
Tracking bugs were a solution found to bypass Bugzilla's limitations. We should look at the reasons why tracking bugs are created, and whether Phabricator can offer a better context for them.
"Small" tracking bugs aim to be an explicit temporary umbrella for several inter-related bugs (i.e. convert all icons to SVG). These can be just tasks with subtasks. They could have the "(tracking)" text in the title and/or they could be added to a "Tracking" project to track the tracking tasks. ;)
"Big" tracking bugs are there to stay and assume in fact some kind of cross-product project behavior and usually they are there to stay (i.e. fix all the documentation). These look like plain Phabricator projects to me.
There are probably many small tracking bugs and a few big ones. The first ones can be create by any registered user, the second ones would need to go through the request process to keep naming conventions (when we have them), avoid duplication, etc.
Would this work?
PS: note the precedent of T423: Create list of performance-related improvements for Jenkins jobs.
Comment Actions
aklapper wrote on 2014-07-24 12:34:44 (UTC)
I covered this to some extend in T434.
Tracking bugs are "allowed" in Phabricator as you can create a task and add dependencies. That's exactly the same functionality as in Bugzilla which people (ab)used when they didn't have a keyword instead.
I don't see any difference and nothing additional to document currently.
Comment Actions
aklapper wrote on 2014-07-29 14:38:51 (UTC)
Closing as I'm not sure what is asked for in this ticket.