[Development] Pending Jira changes
Hi, I looked into the desired workflow changes for Jira (as discussed on this list) and am doing some general cleanups which I would like to bring up at this point. The more invasive bulk changes will happen on Monday while others have already happened. Please note that this may temporarily reduce the responsiveness of the system. 1.) I merged the Resolved, Closed and Verified states into a single state and added a shortcut from Open to Closed. I also took the liberty of renaming some of the transitions based on perceived usability and partly due to system requirements. The new workflow is as follows: https://bugreports.qt-project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=Qt%20Bug%20Tracking%20v2.0stepId=8width=fullheight=full Every Suggestion, Bug and Task issue will get this update. Any issue that is currently Resolved, Verified or Closed will be transitioned to the Closed state. If you have any concerns about the modified workflow please raise them now. 2.) The QTJIRA project had a very inappropriate workflow and permission set. It was updated to carry the new Qt Bug workflow already. From now on it has the same setup as every other project. The only difference is that the project will not carry the OG Approvers group. Practically this means that you can expect the project permissions to behave such as if you don't have approver rights (if you have them). The project is again actively managed by jira admins now. Please use it if required. 3.) We had a lot of dead projects in Jira. While no project was deleted they have been put into storage. Some projects will no longer be visible and others will be read-only. The assumption is that we may still want to refer to the read-only projects later on whereas the invisible ones are truly dead. This affects the following projects: Read-Only: - Qt on Raspberry Pi - Qt Quick Components - Qt Solutions - Qt Webkit - Qt Mobility Invisible - Nokia Qt SDK - Qt Jambi - Qt Modularization Please raise your voice if you think one of those categories is inappropriate for those projects. Planned changes: As I have time during the next couple weeks I will further cleanup some of the undesirable artifacts in the system. This includes the removal of workflow/issue differences between for example the QtCreator and Qt project (the Qt project being the desired target) , remove and consolidate issue types and cleanup of old Nokia groups and roles. Also, I would like to know whether anybody still uses Greenhopper. Without further comments I'll assume that Greenhopper is no longer required and we may remove it in the future. Thank you for your understanding and feedback. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New JIRA type 'Feature'? (was RE: FW: Proposal for RFC like feature process)
Just for the protocol. I am actually in favor of Kai's proposal. It is better than some mega release task as his proposal actually permits to see tasks which are not yet scheduled for any particular release. -- Alex From: Koehne Kai Sent: Wednesday, August 14, 2013 09:03 To: Blasche Alexander; Alan Alpert; Bubke Marco Cc: development@qt-project.org Subject: New JIRA type 'Feature'? (was RE: [Development] FW: Proposal for RFC like feature process) Alright, discussion about a new JIRA type 'Feature' went on at https://bugreports.qt-project.org/browse/QTJIRA-233 with two different ideas: 1) That we already have too many issue types in JIRA, and adding another one makes things just worse, since the line between different types is blurry anyway 2) that a separate 'Feature' type that's can only be created by approvers, and follows stricter standards, is a good thing to let roadmap / important features stand out I personally think it's useful, but also think it only makes sense if the type is really used by at least the majority of maintainers ... So, I'd like to ask specifically you, the maintainers: Would you use a separate 'Feature' type? This is meant to describe things that typically would show up on a roadmap release blog, or that you'd want to discuss with stakeholders ... Regards Kai -Original Message- From: Blasche Alexander Sent: Tuesday, August 13, 2013 1:32 PM To: Koehne Kai; Koehne Kai; Alan Alpert; Bubke Marco Cc: development@qt-project.org Subject: RE: [Development] FW: Proposal for RFC like feature process Creating an issue type is very easy. What's not easy is to commonly agree on what each type means and to consistently apply them. That's something where no admin can help as the community has to agree upon it. For what is is worth I am very much in favor of such a feature type. -- Alex rant Unless a benevolent dictator comes around my experience tells me that there won't be an agreement any time soon(10 years of issue tracking inside Qt seem to have gotten the better of me). /rant From: development-bounces+alexander.blasche=digia@qt-project.org [development-bounces+alexander.blasche=digia@qt-project.org] on behalf of Koehne Kai [kai.koe...@digia.com] Sent: Tuesday, August 13, 2013 12:46 To: Koehne Kai; Alan Alpert; Bubke Marco Cc: development@qt-project.org Subject: Re: [Development] FW: Proposal for RFC like feature process -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org One idea to handle this would be to add yet another issue type, e.g. 'Feature' [...] https://bugreports.qt-project.org/browse/QTJIRA-233 :) Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
-- Alex -Original Message- From: development-bounces+alexander.blasche=digia@qt-project.org [mailto:development-bounces+alexander.blasche=digia.com@qt- On terça-feira, 30 de julho de 2013 11:00:22, Blasche Alexander wrote: How do I set an estimation value? There must be a way to specify the estimation/target. Please don’t offer the Meta task for release x.y option or just a comment. A filter must be able to find the tasks planned for release x.y . The idea from the people in the discussion was that we shouldn't estimate. We're very bad at it. Instead of estimating, I'd go for some generic names that match the branches: any release any minor (feature) release any major release This is not estimation, it's just information about which type of release can contain the change. And those won't require jolly-bumping of versions after a release. Hm this doesn't help me since I have tasks which I want to achieve for the next release (e.g. 5.2) and some which I want for any minor release thereafter. It is merely a todo list for myself. If it is about the bumping then I am happy to bump my own tasks but I need to maintain the list for the next minor release. As long as it is not closed it is not 100% sure anyway. Why don't we accept that any fix in for a non-closed task is a bad estimate. No guarantee. Then we don't have any problems here. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
Now I am confused. We don’t want to use “Fixed Version” for estimation. At the same time you say having two different fields is confusing. How do I set an estimation value? There must be a way to specify the estimation/target. Please don’t offer the Meta task for release x.y option or just a comment. A filter must be able to find the tasks planned for release x.y . -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org [mailto:development-bounces+alexander.blasche=digia@qt-project.org] On Behalf Of Motyka Rafal Sent: Tuesday, 30 July 2013 12:41 To: Nowacki Jedrzej; development@qt-project.org Subject: Re: [Development] Bug management and jira workflow Hello, This clarification was needed: - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation Otherwise, having a field with two different meanings (like ‘fixed in’ and ‘planned to be fixed in’) would lead to confusion. Thanks! Regards, /Rafal Rafal Motyka Quality Assurance Digia, Qt Email: rafal.mot...@digia.commailto:rafal.mot...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qthttp://www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - -Original Message- From: development-bounces+rafal.motyka=digia@qt-project.orgmailto:development-bounces+rafal.motyka=digia@qt-project.org [mailto:development-bounces+rafal.motyka=digia@qt-project.org] On Behalf Of Jedrzej Nowacki Sent: 23. juli 2013 13:26 To: development@qt-project.orgmailto:development@qt-project.org Subject: [Development] Bug management and jira workflow Hi, At the Qt Contributor Summit, we had a really good discussion about bugs and jira, here is the summary: - We have untriaged bugs, we may not be able to triage them all, but we should keep it’s count as low as possible. - We agreed on “triaging” definition. Triaging consist of: - checking if a bug report is sensible. It means the reported issue is not a result of a user mistake, use of undefined behavior etc. - checking if a bug report is not missing an important data, so it would be possible to reproduce it in future - setting a priority - optionally the bug report may be verified. It it is reproduced then it should be accept which means moved to open state Rationale: It looks like the most common behavior of people triaging bugs. - Who can prioritize bugs? - whoever ask - we will create a special group in jira - approvers should be in the group by default Rationale: We do not have man power and we need help. We do not expect anyone to destroy our precious bugs reports or play “ping pong” with a priority. - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation - we know that it can be filled automatically, it would be nice to implement that. - Jira workflow was designed for much bigger team, that includes QA department, it should be simplify - We decided that “in progress” state means that someone started work on a bug or it have a fix which is not merged yet. Time statistics doesn’t show anything, anyway. - Resolved, Verified and Closed should be merged to a single state. Nobody is going through Resloved bugs to verify them. - It would be nice to have a transition from Open to Closed state Cheers, Jędrek ___ Development mailing list Development@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
-Original Message- From: development-bounces+alexander.blasche=digia@qt-project.org - Who can prioritize bugs? - whoever ask - we will create a special group in jira we already have it (Triagers) ... it's just not wired yet. Good, who can wire the group? Why do we need yet another group? Any approver can do that already. Or what am I missing? we have some more groups which are kinda redundant or plain weird: Developers vs. OGApprovers (the latter seems pointless; the former is a default group, if i got it right). Qt - ?!? then there is a whole bunch of company-related groups. i don't think they have much value at this point. just clear them out? lastly, there is a lot of component-related groups. do we consider these having any value? They don't have much value. Unfortunately cleaning them out is a major pain as they have references to Permission, Notification and security schemes and here we are not even talking about all the custom filters. - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation i'm not sure i like that. i thoroughly dislike the idea of the release blocker meta-tasks. this is exactly what a prospective fix version plus the right filter would do. that of course implies that the field must be used exclusively as a deadline designation, not an expession of wishful thinking. Yes, we were discussing which definition we should pick. We decided that not using the field for estimation is better from a random user point of view, that could check which Qt version is actually fixed, without cloning the repository. It doesn't create a wish list either. It seems to be also aligned with idea of time based releases, that changes are released, only if they were merged before a certain date. I can see where there might be a confusion. However if I have a choice between the double loading of the Fix for Version and a release blocker task then I vote for the FixFor version field. The release blocker task doesn't even come close to a replacement. One of the most common filters is What's unresolved and assigned to me for the next release?. Fix for is exactly what you need in this case. Also, as long as the task is not closed it can never be mistaken for a really fixed case anyway. A somewhat better method would be to Split the FixFor field into two fields (e.g. PlannedFor vs FixedIn). But even if we assume that FixFor really means released in version x.y.z, who is going to set it? You cannot set the field until very late in the process. That's exactly what you would do during the Verified-Closed transition (BTW the transition is called Release) and the most likely candidate would be the release team. However this collides with the desire to merge the Resolved/Verified/Closed states because nobody transitions the verified tasks to closed. To me this sounds like the same problem. Nobody wants to clean the tasks right before the release. On the other hand you can actually use the Verified to Closed transition to disambiguate the meaning of FixFor. If it is not closed then it always means that the field is an estimation. If it is closed then it's either part of a release line or it was rejected/invalid/ignored (which means FixFor is invalid anyway). It does imply some issue massaging shortly before the release though. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (Re-)Introducing Alex Blasche
Hi Lorn, Good to see you back working with Qt. Thank you for all the well wishes I have received. It definitely provides a warm welcome. From: Lorn Potter [lorn.pot...@gmail.com] Alex will start his work by going through the modules that were part of Qt mobility in 4.x times and that we haven't made a part of Qt 5 yet. We then hope to have a good understanding of how we'd like to proceed with these modules within a few weeks from now, and when and how we can bring these modules back as an integral part of Qt 5.x. Good news here. As maintainer of qsysteminfo, please try and include me in any discussions regarding this. As I have a few ideas. Nothing would be further from my mind than not involving you. Please keep an eye on the #qt-mobility channel. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
