On Wed, Jun 29, 2022 at 1:17 AM Tim Jacomb <timjaco...@gmail.com> wrote: > I've updated the JEP, could you please take another look when you have time?
My sense from reviewing the additions is that GitHub issues lacks feature parity with Jira on a number of fronts and that preserving existing functionality without regression could only be achieved with significant development effort to write and maintain automation/bots (or adapt existing ones like Prow or Skara) to work around these deficiencies. I think the cost of this is high compared to the cost of staying on Jira (moving from traditional hosted Jira to Jira Cloud when it becomes necessary) and thereby retaining existing functionality without needing to invest our own development effort. Given our limited development resources, my preference would be for us to use Jira for all issue tracking and focus our development resources on the existing backlog of user-impacting frontend and backend projects. In general I think we are stretched thin enough that building in-house infrastructure is impractical for us; despite the strong arguments by Dan Luu in favor of building rather than buying in https://danluu.com/nothing-works/ my experience is that this works better when one is starting from a material position of strength. > It is expected that all repositories will transition from Jira to GitHub I think this statement implies that plugin maintainers would be expected to take action to migrate their repositories, because if it did not imply that, then I would expect to see a migration plan outlined in the JEP. This expectation seems flawed to me, as I generally think it is incumbent on the party implementing a large-scale migration to make a good faith effort to migrate the vast majority of consumers, as was done in JEP-227 and JEP-233. Obviously there is a point of diminishing returns to such efforts, and different people have different thresholds as to what that point is, but the basic point is that the burden on core and plugin maintainers should be minimized as much as possible and ideally eliminated completely but for specific (justified) exceptions. For example, moving from our traditional Jira server to Jira Software Cloud (with HTTP redirects if necessary) would be almost completely transparent to core and plugin maintainers from the perspective of existing Jira issues, which are the vast majority of our existing issues. > For Jenkins core issues we make use of ChatOps to allow people without > privileges to do some triage themselves. But this does not address the problem of labels in plugins. I see no reason why core would be any different from a plugin from the perspective of users needing to be able to label issues (e.g., for tables-to-divs or SVG icon issues in plugins). > If we do wish to maintain the ability to move issues for anyone or at least > org members Per JEP-1, JEP submissions should contain "a minimal prototype implementation sufficient to convey the viability of the design". I do not see a minimal prototype implementation of this functionality in the JEP submission. > Look at the any issue references that show in the issue view But these issue references do not appear in one place in the issue view: they are scattered throughout the issue comments, making them hard to find in long threads. Also I cannot see a way to delete an incorrect issue reference, so incorrect issue references will clutter the view as well. In contrast, Jira displays the linked issues in one visual area, and it provides rich functionality to add, remove, and edit these links, even allowing you to link to an arbitrary web page with your own title if the existing relationships are unsuitable. > Use a GitHub search […] Use a GitHub issue filter in the repository Seems fragile, as it relies on a non-standard schema ("Caused by: https://github.com/organization/repository/issues/ID";). Users might not be aware of this (which would be completely understandable given the lack of a UI) or might misspell the phrase "Caused by" (or use a slightly different phrase), and it is unclear to me whether variations of the issue URL (e.g., no https, just "#ID", or just "organization/repository#ID") would all be searchable the same way. Altogether seems weaker than Jira, and I do not think the searching syntax is as rich as Jira Query Language (JQL). > Custom fields and statuses Unclear to me how a regular one-off issue in core or a plugin would have the release version recorded if it is not part of a GitHub project (i.e. Jira epic). Many smaller one-off issues are not part of any GitHub project (i.e. Jira epic), but Jira still provides visibility into their status (e.g. "In Progress", "In Review", etc) and released version. I think this proposal would regress this functionality for issues that are not part of a GitHub project (i.e. Jira epic), which are the majority of one-off bug fixes. This could possibly be worked around with a "catch-all" GitHub project, but I see no mention of this in the JEP and I think it could be awkward to implement. > It is also common to have a bot that comments on an issue when it has been > released in a version. Sure but see my earlier comments about JEP-1. My point is that reaching feature parity sounds like it would require a significant amount of (as-yet pending) development effort, to say nothing of long-term maintenance. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpdxyr7DTDxeMd_qZ27p6_v0gf719n67H4WhX7b9VuN0Q%40mail.gmail.com.
