[Jenkins-infra] Proposal: Add optional "Released as" and "Stage Release" states to JIRA

Oleg Nenashev o.v.nenashev at gmail.com
Tue Aug 15 10:03:38 UTC 2017


Hi James,


> I am merely giving a reasonable response to the proposal, which I think is
> fair, given I am the component leader on projects cited as benefiting from
> this change.
>

Well, in your previous response you gave feedback about the existing
process. Correct me if I am wrong.
In the new feedback I see the response to the proposal, hence please find
my response below:

The tool we use already makes provisions for the problems outlined.
> Additional statuses will not add clarity as this is now how JIRA projects
> are usually used which runs contrary to user expectations of this widely
> used tool.
>

It may be contrary for a manager (sorry, I really do not understand what's
your point in this sentense), but IMHO it's a straighforward improvement
for Jenkins users.

   - Before: Users were seeing changes as "Resolved", but it was not a
   guarantee that the change is acually delivered
   - After (in core components): When the change is Resolved, the version
   is available for download

As we discussed with Ulli above, as a plugin maintainer you can stick to
the current flow in your components.

Secondly, as someone who spends much time in JIRA who would benefit from
> tracking such information, the proposed fields cannot be used in
> conjunction with JIRA reporting functionality such as Created vs Resolved
> charts, which are very beneficial to those who manage triaging and tracking
> the health of sub-projects.


They can be used. For such purpose there are meta-statuses like "Open". If
dashboards depend on raw status (e.g. "In Progress"), they may need an
update of course. If the proposal gets approved, I will make sure it's
announced accordingly.
We have also added the "In Review" status according to your request
<https://groups.google.com/forum/#%21searchin/jenkinsci-dev/%22In$20Review%22%7Csort:relevance/jenkinsci-dev/mEqAQmPJ5xM/ezVBBB6tAwAJ>
one year ago, and one could grumble about the same impact on reporting. How
does this request differ from your one in terms of reporting?

BR, Oleg



2017-08-15 10:52 GMT+02:00 James Dumay <jdumay at cloudbees.com>:

> I am merely giving a reasonable response to the proposal, which I think is
> fair, given I am the component leader on projects cited as benefiting from
> this change.
>
> The tool we use already makes provisions for the problems outlined.
> Additional statuses will not add clarity as this is now how JIRA projects
> are usually used which runs contrary to user expectations of this widely
> used tool.
>
> Secondly, as someone who spends much time in JIRA who would benefit from
> tracking such information, the proposed fields cannot be used in
> conjunction with JIRA reporting functionality such as Created vs Resolved
> charts, which are very beneficial to those who manage triaging and tracking
> the health of sub-projects.
>
>
> On Tuesday, August 15, 2017 at 6:34:20 PM UTC+10, Oleg Nenashev wrote:
>>
>> Hi James,
>>
>>
>>> -1 JIRA was designed to have a project per software lifecycle. The fact
>>> that we have 1000 plugins in the same JENKINS project breaks all the nice
>>> things about JIRA, such as the Fixed For field and Versions, which was
>>> designed for this very problem.
>>
>>
>> I know you do not like the current JIRA structure, but I do not see how
>> your comment is related to the proposal. I want to improve the current
>> project structure, not to create a new one.
>>
>> If you want to change the JIRA design and to decouple plugins to
>> projects, feel free to do it in a separate thread
>>
>> BR, Oleg
>>
>>
>> 2017-08-15 9:19 GMT+02:00 James Dumay <jdu... at cloudbees.com>:
>>
>>> -1 JIRA was designed to have a project per software lifecycle. The fact
>>> that we have 1000 plugins in the same JENKINS project breaks all the nice
>>> things about JIRA, such as the Fixed For field and Versions, which was
>>> designed for this very problem.
>>>
>>>
>>> On Monday, August 14, 2017 at 7:45:08 PM UTC+10, Oleg Nenashev wrote:
>>>>
>>>> Hi all,
>>>>
>>>> As a Jenkins user and contributor, I sometimes have difficulties when I
>>>> need to understand in which release the fix is available. GitHub commit
>>>> links from the bot help much, but it requires extra time to navigate across
>>>> commits and UI. In Jenkins core, Remoting and my plugins I would like to
>>>> make it more explicit:
>>>>
>>>> I propose to...
>>>>
>>>>    1. Modify workflow in the JENKINS project:
>>>>       - Add a "Stage Release" state (or whatever similar name)
>>>>       - Instead of "In Progress" => "Resolved", contributors can move
>>>>       integrated fixed into the "Stage Release" state.
>>>>       - It may be helpful for components which do not release the
>>>>       integrated fixes immediately (e.g. Core, its modules, Remoting, Stapler,
>>>>       Blue Ocean, other plugins)
>>>>       2. Add an optional "Released As" field to JIRA (type=String)
>>>>       - When a contributor moves the issue to "Stage release",
>>>>       "Resolved" or "Closed" state, an optional field appears in the dialog
>>>>       - If the field is non-empty, it will appear in the ticket
>>>>       header, hence users won't need to look into comments and commit histories
>>>>
>>>> This proposal could improve contributor and user experience, but the
>>>> proposed change is opt-in.
>>>>
>>>> It does not make the field/state mandatory, hence the existing flows
>>>> won't be affected if the maintainers do not want to spend time on JIRA
>>>> updates.
>>>>
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> Thanks in advance,
>>>>
>>>> Oleg
>>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Jenkins Developers" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/jenkinsci-dev/wzc4VLplHvs/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> jenkinsci-de... at googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-dev/a835c953-65a4-44a7-b1f0-55384d0498e9%40goo
>>> glegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/a835c953-65a4-44a7-b1f0-55384d0498e9%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-dev/wzc4VLplHvs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscribe at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/61e48fa9-5b59-4ee8-8e2c-227376c251b7%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/61e48fa9-5b59-4ee8-8e2c-227376c251b7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20170815/9f80786c/attachment.html>


More information about the Jenkins-infra mailing list