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 <[email protected]>: > -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/ > topic/jenkinsci-dev/wzc4VLplHvs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/a835c953-65a4-44a7-b1f0-55384d0498e9% > 40googlegroups.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 the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCg6S63UH5n-sLbSbWDOF%3DT-3Xh_1bbCy%2BmnhBGjuzV4w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
