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
