Hi Cathy, I understand your POV on updating PTREL workflow: so we shouldn't create Tizen:Generic bugs here, but somewhere else.
If some QA is made official on T:Generic, we'll then need a specific Jira project to sync developers, RE and QA with a usual workflow (like IVI for example). Is it how things should be done ? For the script, I think we can share a lot of things because it's based on gerrit and git queries: I'll ask Kevin Thierry who developed this to post in a public github repo. Thanks for feedback, -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 On 17/03/2014 07:07, Shen, Cathy wrote: > Hi Stéphane, > >> -----Original Message----- >> From: Stéphane Desneux [mailto:[email protected]] >> Sent: Sunday, March 16, 2014 10:30 PM >> To: Shen, Cathy >> Cc: Łukasz Stelmach; Marc Hiebel; [email protected] >> Subject: Re: [Dev] Jira worflow enhancement for PTREL project possible ? >> >> Hi Cathy, >> >> Shen, Cathy wrote: >>> The workflow is defined and aligned several months ago with architects and >>> PMs. >> The basic logic is to simplify the workflow for bug tracking. >>> There are other alternative way to show the assignee is working on this >>> issue, e.g. >> use label. >>> For "released" status, it need lots of RE's efforts to mark bugs from >>> resolved to >> released, especially when there is no bug ID information in committed patch. >> We >> have awful experience in previous projects. :( The alternative and >> lightweight >> solution might be: only when patches are merged by RE with tag >> "accepted/xxxx", >> the bug can be marked as resolved by developer and the commit ID should be >> provided in comments for easy search. >> >> Just a remark: being one of the REs for Tizen:Generic, I regularly see some >> commits tagged as accepted/xxx but finally not built in OBS (the requests are >> sometimes accepted then revoked later because of build problems but this >> doesn't >> remove the tag accepted/xxx). >> >> So basically, the tools used in gerrit and OBS to track changes are >> incomplete. >> They usually work as described, but not always. Before understanding this, if >> you're confident in accepted/xxx tags, you'll get a lot of surprises :-) >> >> >> For the more general problem on bugs workflow on PTREL: the workflow is too >> limited and REs have to work by hand (with their own tools and spreadsheets) >> to >> get the work done: we now have a few scripts that track gerrit and OBS states >> and determine if a merged patch has been submitted or not, if it's released >> or >> not etc. But we have to do this privately because such states don't exist in >> Jira. >> >> See the attached table for ~200 multiuser patches and you'll see the problem: >> for a given status in Jira, there are multiple status in real life: assigned, >> (really) in progress, in review, reviewed (but not merged!), merged (but not >> submitted), submitted. So we have to track them by hand... It's an effort >> and a >> waste of time, as the one you describe, but without any official tool ! >> > Your script to generate the detail bug status is cool! I believe other REs' > will love it, too. Is it possible to share it with others or automated update > the table in a public website? > Back to the workflow, I still hesitate to introduce so complex workflow in > JIRA, it's quite time consuming to make everyone understand the exact meaning > of the status. And most time consuming thing is not to generate the status > table if you've already have the script, but to update JIRA tickets with > exact status one by one manually. > Even we have the automated scripts or tool to update JIRA tickets > automatically, we still can't handle some cases, e.g. sometime bugs are fixed > (or can't be reproduced) with unknown reason. We have to handle them in JIRA > manually. > PTREL is designed for Tizen release project, but not for Tizen generic only, > we need consider about other profiles' requests as well. > >> Conclusion: IMO, tt's better to have a more precise workflow and have REs do >> their work with common, public tools and procedures than having the same >> people >> do the work with their own private tools and procedures. Probably less >> effort, >> more visibility and more exchanges with developers/maintainers. >> >> BR, >> Stéphane >> >> -- >> Stéphane Desneux >> Intel OTC - Vannes/FR _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
