Proposal: Add optional "Released as" and "Stage Release" states to JIRA

[Oleg Nenashev]

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

[Alex Johnson]

+1 I've spent a ton of time sifting through blame or repo tags, and this could also be useful for features/API updates too. At the least adding the `Released As` field would suffice

[Mark Waite]

I'm in favor of adding the extra field and adding the additional state.

Mark Waite

[Jesse Glick]

+1, I have seen people get confused when an issue is moved to
Resolved/Fixed after a PR is merged yet the fix is not available on
the update center. IIUC this proposal would allow us to have an
intermediate state between In Review and Resolved/Fixed.

(BTW I am not sure what the Closed resolution is for.)

[Oleg Nenashev]

IIUC this proposal would allow us to have an intermediate state between In Review and Resolved/Fixed.

Exactly

 

+1, I have seen people get confused when an issue is moved to
Resolved/Fixed after a PR is merged yet the fix is not available on
the update center.

Good point. Once we have the fix, we will be able to update Jenkins Issue autoupdater to move the
issues to the "Stage Release" state instead of "Resolved".

 

(BTW I am not sure what the Closed resolution is for.)

Nobody knows :(

Maybe we want to just remove it and merge with Resolved

 

--
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@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3BF8cn17%2Bs_5dAHzfK_%3DewW7B%3D0vSGGSiWfE_fBpGwew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel Beck]

> On 14. Aug 2017, at 11:45, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> WDYT?

I'd be happy to add this to the workflow. Feedback seems positive, but let's wait a few more days first.

Would like to know:
- New state name? "Stage Release"
- Which transitions to add (probably from Closed, Resolved, Open, In Progress, and In Review) and what to call them.

We can probably just go with the boring but unambiguous 'Fixed and Unreleased' (new) and 'Fixed and Released' (the old 'Fixed'), and change transition labels accordingly to 'Resolve' and 'Resolve and Mark Released' or so...

[Richard Bywater]

FWIW I think there may still be some room for resolved vs closed if you were say to make resolved mean released and then closed is once the issue has been released for a period of time and "burnt in". So one you might still be keeping an eye out for vs the other is long gone and can be "forgotten about".

Richard.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

[Ullrich Hafner]

 

(BTW I am not sure what the Closed resolution is for.)

Nobody knows :(

Maybe we want to just remove it and merge with Resolved

 

Actually Closed is used to mark that an issue actually has been verified to be fixed in a released version. Normally this is done by the reporter (or in other projects by QA). 

[Ullrich Hafner]

Am 14.08.2017 um 17:10 schrieb Oleg Nenashev <o.v.ne...@gmail.com>:

IIUC this proposal would allow us to have an intermediate state between In Review and Resolved/Fixed.

That makes our workflow complex to understand for others. Who is responsible to move the issues from the new state to resolved? If you consider to add another state please make it optional and do not change the default (and simple) workflow for plugin authors.  

Exactly

 

+1, I have seen people get confused when an issue is moved to
Resolved/Fixed after a PR is merged yet the fix is not available on
the update center.

Good point. Once we have the fix, we will be able to update Jenkins Issue autoupdater to move the
issues to the "Stage Release" state instead of "Resolved".

Please do not change the current behavior. Most plugin authors do not need such an overly complex workflow. We just fix some issues, make a release and move forward to the next ones. 

 

(BTW I am not sure what the Closed resolution is for.)

Nobody knows :(

Maybe we want to just remove it and merge with Resolved

 

2017-08-14 17:07 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:

+1, I have seen people get confused when an issue is moved to
Resolved/Fixed after a PR is merged yet the fix is not available on
the update center. IIUC this proposal would allow us to have an
intermediate state between In Review and Resolved/Fixed.

(BTW I am not sure what the Closed resolution is for.)

--
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@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3BF8cn17%2Bs_5dAHzfK_%3DewW7B%3D0vSGGSiWfE_fBpGwew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLAx%2B8oN8dBU4a59PbrEp8ZnO_YFWBcgB2Y48uOV06_FUw%40mail.gmail.com.

[Ullrich Hafner]

> Am 14.08.2017 um 17:38 schrieb Daniel Beck <m...@beckweb.net>:
>
>
>> On 14. Aug 2017, at 11:45, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>>
>> WDYT?
>
> I'd be happy to add this to the workflow. Feedback seems positive, but let's wait a few more days first.
>
> Would like to know:

> - New state name? "Stage Release“

I’m not a native speaker but Stage Release seems to be grammatically different from the other ones: Closed, Resolved, In Progress

> - Which transitions to add (probably from Closed, Resolved, Open, In Progress, and In Review) and what to call them.
>

From Closed it makes no sense for me, Closed means already released.

> We can probably just go with the boring but unambiguous 'Fixed and Unreleased' (new) and 'Fixed and Released' (the old 'Fixed'), and change transition labels accordingly to 'Resolve' and 'Resolve and Mark Released' or so…
>

Please don’t change the default names in Jira, there are so many people that use Jira in other projects.

[Daniel Beck]

> On 14. Aug 2017, at 23:54, Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> Please don’t change the default names in Jira, there are so many people that use Jira in other projects.

I'm open to alternatives. Try to make them unambiguous though.

[Oleg Nenashev]

Hi Ulli,

Thanks for the feedback, please find my responses below

Am 14.08.2017 um 17:10 schrieb Oleg Nenashev <o.v.ne...@gmail.com>:

IIUC this proposal would allow us to have an intermediate state between In Review and Resolved/Fixed.

That makes our workflow complex to understand for others. Who is responsible to move the issues from the new state to resolved? If you consider to add another state please make it optional and do not change the default (and simple) workflow for plugin authors. 

I do not propose to enforce this state everywhere.  My proposal is to add such state and transitions required like we previously did for "In Review". If plugin authors do not want to use the new state in their plugins, they can continue using the current transition graphs (e.g. "New" => "In Progress" => "Resolved") without any issues. The only thing they will see is an additional option in the dropdowns when they select the state to set.

Exactly

 

+1, I have seen people get confused when an issue is moved to
Resolved/Fixed after a PR is merged yet the fix is not available on
the update center.

Good point. Once we have the fix, we will be able to update Jenkins Issue autoupdater to move the
issues to the "Stage Release" state instead of "Resolved".

Please do not change the current behavior. Most plugin authors do not need such an overly complex workflow. We just fix some issues, make a release and move forward to the next ones.

We could change the flow only for particular components (Jenkins core, modules, remoting) and keep the original one for plugins.

Though I would rather prefer to have the proposed change for my plugins as well, we could meet on the middle in this case.

Would it work for you?

> Would like to know:
> - New state name? "Stage Release“

I’m not a native speaker but Stage Release seems to be grammatically different from the other ones: Closed, Resolved, In Progress

 

I am open to other name proposals.

>
> Please don’t change the default names in Jira, there are so many people that use Jira in other projects.

+1,  there is not so much benefit in renaming the existing names.

Maybe we could just name the new state as "Needs Release" or "To Be Released" or whatever.

(BTW I am not sure what the Closed resolution is for.)

Nobody knows :(

Maybe we want to just remove it and merge with Resolved

 

Actually Closed is used to mark that an issue actually has been verified to be fixed in a released version. Normally this is done by the reporter (or in other projects by QA).

Well, in Jenkins JIRA it does not happen from what I see.

I think we could keep "Resolved" and "Closed" as is for now.

BR, 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/topic/jenkinsci-dev/wzc4VLplHvs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4F160C4F-DD13-4B73-948F-668C77DEB0DA%40beckweb.net.

[James Dumay]

-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.

[Oleg Nenashev]

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

--

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@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a835c953-65a4-44a7-b1f0-55384d0498e9%40googlegroups.com.

[James Dumay]

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.

To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Oleg Nenashev]

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 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

 

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@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.

[Ulli Hafner]

Am 14.08.2017 um 11:45 schrieb Oleg Nenashev <o.v.ne...@gmail.com>:

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
  

It would be awesome if the issue updater could fill in the correct value by extracting the Pom version.

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 the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/521bcc90-6ab0-42ec-b6b6-aeb6c225e901%40googlegroups.com.

[Oleg Nenashev]

It would be awesome if the issue updater could fill in the correct value by extracting the Pom version.

I could try to do it (download POM, read version, remove "-SNAPSHOT") in the issue updater, but it presumes that the plugin version does not change. But yes, it could be helpful.

• CONS: It's a common case when 4.2-SNAPSHOT gets changed to 4.1.1-SNAPSHOT by the maintainer before the release in order to ship a hotfix. In such case the "Released As" field may be incorrect.
• In such case the plugin maintainer would have to manually update tickets

Ideally we could add a maven release watcher, which updates the fields after the release by scanning commit history. It's something doable, but I'd guess we would be reimplementing an already existing Maven <Whatever> Changelog plugin engine.

Machine-readable and auto-generated changelogs would be a valiant goal for us, because we could use the data in Plugin Site/Update Manager. But it's far beyond the JIRA update proposal.

BR, Oleg

2017-08-15 12:55 GMT+02:00 Ulli Hafner <ullrich...@gmail.com>:

Am 14.08.2017 um 11:45 schrieb Oleg Nenashev <o.v.ne...@gmail.com>:

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
  

It would be awesome if the issue updater could fill in the correct value by extracting the Pom version.

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 the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/521bcc90-6ab0-42ec-b6b6-aeb6c225e901%40googlegroups.com.
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@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/710C9068-A180-4F72-8CCA-6F27D09287F5%40gmail.com.

[Oleg Nenashev]

Hi all,

Since there is some disagreement, I have added the topic to the tomorrow's agenda
I have created a Google Doc with the proposals and incorporated comments there.

Please let me know if I've missed something

BR, Oleg


вторник, 15 августа 2017 г., 13:05:58 UTC+2 пользователь Oleg Nenashev написал:

[Daniel Beck]

> On 15. Aug 2017, at 19:58, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> Since there is some disagreement, I have added the topic to the tomorrow's agenda

We can discuss it, and perhaps work out a complete proposal, but we should not reach a conclusion there, as it excludes too many people unable to be present at the specific time.

[Oleg Nenashev]

We can discuss it, and perhaps work out a complete proposal, but we should not reach a conclusion there, as it excludes too many people unable to be present at the specific time.

Fine for me, especially since James Dumay is not in the right timezone to attend.

Everybody can comment in the referenced Google doc and to add proposals.

BR, 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/topic/jenkinsci-dev/wzc4VLplHvs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/E0EE9A09-C581-4C69-A01E-0986A0196BF8%40beckweb.net.

[Oleg Nenashev]

I am going to create a JEP for this change.
Who would be interested to be a BDFL Delegate? In the case of the core it would be @Daniel, but maybe somebody from plugin maintainers wants to participate as well

BR, Oleg

вторник, 15 августа 2017 г., 21:22:39 UTC+2 пользователь Oleg Nenashev написал:

[Oleg Nenashev]

Created https://github.com/jenkinsci/jep/pull/47

пятница, 26 января 2018 г., 18:54:01 UTC+1 пользователь Oleg Nenashev написал:

[R. Tyler Croy]

I had a conversation with Oleg about this last week in the #jenkins-community
channel, which I promised I would summarize here. After reading the JEP and
discussing with Oleg a bit, I think this is a reasonable enhancement and has
little to no negative impact, so +1.

The primary question I had was wheter JEP-3 would continue to be relevant if Blue
Ocean, or Pipeline for example, were moved into separate JIRA projects. In
essence, would the "problem be solved" if we moved those specific plugin
subsystems to separate JIRA projects where they could consistently use the
built-in functionality within JIRA for managing versions and releases. Oleg's
proposal is still relevant and beneficial to the "long-tail" of smaller plugin
systems, and individual plugins, which may never merit a single JIRA project
unto themselves.

So yeah, +1 from my perspective to JEP-3 :)


Full log below.

01:58 <oleg-nenashev> rtyler: pong
02:02 <rtyler> I was reading JEP-3 and a question came to my mind, if we had a separate project in JIRA for Pipeline and one for Blue Ocean (for example), JEP-3 would
still be necessary in your mind wouldn't it?
02:31 <oleg-nenashev> It would
02:34 @<danielbeck> for JENKINS probably, the specific projects could do it via versions
02:36 <oleg-nenashev> Yes, BlueOcean could switch to versions
03:10 <oleg-nenashev> I have some reservations about moving BO to a separate project tho
03:11 <oleg-nenashev> Needs to be impkemented properly so that other plugin maintainers are not affected
03:14 <rtyler> why would that negatively affect other plugin maintainers?
04:14 <oleg-nenashev> rtyler: Moving issues is generally more complicated than changing the components, and it takes more time. For multi-project issues (e.g.
BlueOcean+SSE Gateway or BlueOcean + JIRA) it will also require some linking between issues and other such fun
04:17 <oleg-nenashev> rtyler: There is a request from i386 about that somewhere in the mailing lists, cannot find it. Maybe i386 wants to recover the thread for
further discussion. CC danielbeck who participated in the thread as well IIRC
04:21 <oleg-nenashev> BTW, I am not sure whether comments like "I moved to AppVeyor" are appropriate when a core maintainer says so :(
https://github.com/jenkinsci/change-assembly-version-plugin/pull/17#issuecomment-364553617
04:21 <oleg-nenashev> But .NET stack for Jenkins is really abandoned
04:22 <oleg-nenashev> It needs a hero. A full-time hero actually, so /me shrugs
04:37 <rtyler> oleg-nenashev: I don't think i386 is going to recover the thread, I think he was pretty frustrated with all of us for using JIRA shittily
04:37 <rtyler> (which we kinda are, for a number of reasons)
04:38 <oleg-nenashev> yeah
04:38 <oleg-nenashev> I agree with that
04:38 <rtyler> oleg-nenashev: so I was just curious whether other changes made JEP-3 still relevant, and it seems like JEP-3 is
04:38 <rtyler> so I'm going to summarize this discussion and reply to the dev list thread, okay?
04:38 <oleg-nenashev> fine with me
04:39 <oleg-nenashev> Generally I need somebody who is willing to be a BDFL candidate
04:39 <oleg-nenashev> danielbeck or ogondza seem to be obvious candidates since they handle the core JIRA crap, but they didn't reply so far. Maybe you or ulli?
04:40 <rtyler> I don't think I spend enough time in JENKINS to rightfully quality, sorry
05:50 <oleg-nenashev> np




- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

[Kohsuke Kawaguchi]

Thanks Oleg for driving this conversation with perseverance. There was some initial dissent, but between a linked mailing list thread, a midnight conversation in the Jenkins World hackhouse, and an IRC conversation, my understanding is that he built a consensus among people such as Jesse, James, Tyler, and Daniel.

As such, I intend to accept this soon.

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20180212175616.dntzdyauekyb3kps%40blackberry.coupleofllamas.com.

For more options, visit https://groups.google.com/d/optout.

--

Kohsuke Kawaguchi

[Ullrich Hafner]

I’m not sure if this is from a previous change in our Workflow: But the ‚Start Review‘ Workflow step is now the default one for issues. It should be 'Resolve Issue'.  See screenshot. Start Review should be in Workflow Menu.

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/09da1270-4b31-4f27-b627-f5738da25b81%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Oleg Nenashev]

Hi Ulli,

It is unrelated for sire, because the JEP-3 infra tickets (e.g. INFRA-1506) have not been processed by the INFRA team yet.

So I am waiting for their actions regarding that.

BR, Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/09da1270-4b31-4f27-b627-f5738da25b81%40googlegroups.com.
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@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/887278D0-A494-477D-AB28-CB7DBC1819EA%40gmail.com.

[Daniel Beck]

> On 10. Mar 2018, at 12:43, Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> I’m not sure if this is from a previous change in our Workflow: But the ‚Start Review‘ Workflow step is now the default one for issues. It should be 'Resolve Issue'. See screenshot. Start Review should be in Workflow Menu.

This is unrelated to Oleg's plan, and has been the current situation since the 'In Review' state was introduced in summer 2016.[1]

I just looked into this, and I don't know what determines the order of transitions in the menu ("Workflow" is just the overflow in case of more than four transitions). I first thought it's the natural order of the target state (which is configurable), but that doesn't seem to be it: The last transition of Reopened is to In Progress, ordered after Resolve and Close. Workflows don't seem to allow defining sort order.

1: https://groups.google.com/d/msg/jenkinsci-dev/mEqAQmPJ5xM/ezVBBB6tAwAJ

[Oleg Nenashev]

UPD: "Released As" field can be now set when resolving issues (or editing existing ones).

Thanks to Daniel Beck for INFRA-1543.

The "Ready for Release" state still needs to be implemented INFRA-1506, but it is less important to me.

Soon I will be creating sample dashboards for Java 10 and JCasC compatibility, which should simplify maintenance of pages like Plugins affected by fix for JEP-200

BR, Oleg

[Jesse Glick]

On Mon, Jul 9, 2018 at 5:03 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> The "Ready for Release" state still needs to be implemented INFRA-1506

+1, would like to see this.

[Daniel Beck]

> On 9. Jul 2018, at 23:03, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> The "Ready for Release" state still needs to be implemented INFRA-1506, but it is less important to me.
>

Sorry about that. I will look into that tomorrow. The first time I looked at it, it was underspecified, but you later clarified that on IRC, but by then I had moved on to something else.