Sumantro and me were working upon the possibility of shifting QA tickets to some other platform like pagure. Thanks Justin(jflory7) for guiding . Following are the points:- 1. Shifting to Pagure will be easy and efficient. 2. Wiki -----> overview 2. In the Pagure repo, priorities can be set for tickets based on ranking, e.g. 10=urgent,20=high,30=normal, etc.(we can have custom priorities) 3. Milestones----> Pagure milestones(has been improved) 4. Roadmap *All the ticket with the tag roadmap will show up on the roadmap page. *For each milestones defined in the settings of the project, the roadmap will group tickets with the corresponding tag. *Tickets with the tag roadmap that are not associated with any of the milestones defined in the settings are group in an unplanned section.
5. All of the fields in both ticket type and ticket component are likely best implemented in tags for tickets. That would allow for the categorization and grouping of the tickets based on their keywords. 6. The blocked by and blocking feature is available in Pagure as metadata. 7. All other things can be easily implemented using tags. 8. As discussed in the last meeting, https://pagure.io/pagure-importer can be used to import tickets.
I am putting this as a mail because, I wont be able to attend the meeting today.
Thanks and Regards Kanika (a2batic)
On Mon, 2016-09-26 at 11:13 +0530, Kanika Murarka wrote:
Sumantro and me were working upon the possibility of shifting QA tickets to some other platform like pagure. Thanks Justin(jflory7) for guiding . Following are the points:-
- Shifting to Pagure will be easy and efficient.
- Wiki -----> overview
- In the Pagure repo, priorities can be set for tickets based on
ranking, e.g. 10=urgent,20=high,30=normal, etc.(we can have custom priorities) 3. Milestones----> Pagure milestones(has been improved) 4. Roadmap *All the ticket with the tag roadmap will show up on the roadmap page. *For each milestones defined in the settings of the project, the roadmap will group tickets with the corresponding tag. *Tickets with the tag roadmap that are not associated with any of the milestones defined in the settings are group in an unplanned section.
- All of the fields in both ticket type and ticket component are
likely best implemented in tags for tickets. That would allow for the categorization and grouping of the tickets based on their keywords. 6. The blocked by and blocking feature is available in Pagure as metadata. 7. All other things can be easily implemented using tags. 8. As discussed in the last meeting, https://pagure.io/pagure-importer can be used to import tickets.
I am putting this as a mail because, I wont be able to attend the meeting today.
This all seems fine to me, and now F25 is past would be a great time to do it. I've seen some other projects are able to do a 'test' import into a disposable or playground Pagure instance, like https://stg.pagure.io/ ; could we set up a test migration of fedora-qa trac to see how it would look? Thanks!
Hi Adam,
+1 for that, it will give us more confidence to go ahead with pagure :). I will look into the available tools and start with it asap.
Regards Kanika (a2batic)
On 7 December 2016 at 02:35, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-09-26 at 11:13 +0530, Kanika Murarka wrote:
Sumantro and me were working upon the possibility of shifting QA tickets to some other platform like pagure. Thanks Justin(jflory7) for guiding . Following are the points:-
- Shifting to Pagure will be easy and efficient.
- Wiki -----> overview
- In the Pagure repo, priorities can be set for tickets based on
ranking, e.g. 10=urgent,20=high,30=normal, etc.(we can have custom priorities) 3. Milestones----> Pagure milestones(has been improved) 4. Roadmap *All the ticket with the tag roadmap will show up on the roadmap page. *For each milestones defined in the settings of the project, the roadmap will group tickets with the corresponding tag. *Tickets with the tag roadmap that are not associated with any of the milestones defined in the settings are group in an unplanned section.
- All of the fields in both ticket type and ticket component are
likely best implemented in tags for tickets. That would allow for the categorization and grouping of the tickets based on their keywords. 6. The blocked by and blocking feature is available in Pagure as
metadata.
- All other things can be easily implemented using tags.
- As discussed in the last meeting, https://pagure.io/pagure-importer
can be used to import tickets.
I am putting this as a mail because, I wont be able to attend the
meeting today.
This all seems fine to me, and now F25 is past would be a great time to do it. I've seen some other projects are able to do a 'test' import into a disposable or playground Pagure instance, like https://stg.pagure.io/ ; could we set up a test migration of fedora-qa trac to see how it would look? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org
Hi,
Sorry, It took a bit longer time. The demo repository has been setted up here[1]. The repo includes following:- 1. Roadmap contains all the milestone. 2. There are 5 levels of priority:
1. Blocker 2. Critical 3. Major 4. Minor 5. Trivial
3. The keywords, component and type are mentioned as TAGS.
4. I have updated few tickets (#471, #472, #489, #491, #493, #494, #495, #496) for demo.
Please review the same and suggest changes.
[1]https://stg.pagure.io/test-fedoraqa-2
Regards Kanika (a2batic)
On 11 December 2016 at 20:49, Kanika Murarka murarkakanika@gmail.com wrote:
Hi Adam,
+1 for that, it will give us more confidence to go ahead with pagure :). I will look into the available tools and start with it asap.
Regards Kanika (a2batic)
On 7 December 2016 at 02:35, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-09-26 at 11:13 +0530, Kanika Murarka wrote:
Sumantro and me were working upon the possibility of shifting QA tickets to some other platform like pagure. Thanks Justin(jflory7) for guiding . Following are the points:-
- Shifting to Pagure will be easy and efficient.
- Wiki -----> overview
- In the Pagure repo, priorities can be set for tickets based on
ranking, e.g. 10=urgent,20=high,30=normal, etc.(we can have custom priorities) 3. Milestones----> Pagure milestones(has been improved) 4. Roadmap *All the ticket with the tag roadmap will show up on the roadmap page. *For each milestones defined in the settings of the project, the roadmap will group tickets with the corresponding tag. *Tickets with the tag roadmap that are not associated with any of the milestones defined in the settings are group in an unplanned section.
- All of the fields in both ticket type and ticket component are
likely best implemented in tags for tickets. That would allow for the categorization and grouping of the tickets based on their keywords. 6. The blocked by and blocking feature is available in Pagure as
metadata.
- All other things can be easily implemented using tags.
- As discussed in the last meeting, https://pagure.io/pagure-importer
can be used to import tickets.
I am putting this as a mail because, I wont be able to attend the
meeting today.
This all seems fine to me, and now F25 is past would be a great time to do it. I've seen some other projects are able to do a 'test' import into a disposable or playground Pagure instance, like https://stg.pagure.io/ ; could we set up a test migration of fedora-qa trac to see how it would look? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org
-
Adam Williamson -
Kanika Murarka