Many of my opinions have been expressed, and of course my (non-binding) vote for switching to GitHub issues is of little to no consequence.
I wish to acknowledge and yet respond to Gus's reasonable objection to switching to GitHub in addition to a few other comments. It's owned by Microsoft I feel it would be wholly damaging to the Microsoft brand to pull the rug under the many open source projects owned by non-profits and hosted entirely on GitHub. Their leadership is trending toward the good and any absurd actions like that would have very serious ramifications for their business. I think it's a non-issue for the foreseeable future that is outweighed by the benefits of shedding Jira. Furthermore, here's a short list of tutorials <https://gist.github.com/MarcusSorealheis/c3e5055442b89fdf0d32c392e95ea314> for migrating back to Jira in a doomsday scenario. > - No way to enforce that a resolution label is applied to the issue. > > We can enforce labels. It will require some customization to some of the existing options. Here is a popular one <https://github.com/marketplace/actions/require-labels>. > - Document with each issue the Affected version and the fixed version. > > There are many ways to do this one. The simplest is the issue template <https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository>. There are many others, though. Jira is very robust, but it is daunting. It seems that to make this proposal viable, a few members of the community need to commit to setting up and facilitating the transition. To me, it feels like a two month effort. Regarding .patch files, I think there are very few systems that still rely on them. However, there are some projects out there that could add support for ,patch files via email. I did not look into it too much but I did comment on one project's issue requesting such support. I'm not totally sure about what's happening with the project or that feature request. I'm mostly hoping to elicit more details. I respect .patch and Jira. Ultimately, I despise how annoying Jira gets and think that more developers could get involved if we removed that dependency. GitHub actions give us lots of customizability. Best, Marcus On Sun, May 8, 2022 at 8:38 AM Ryan Ernst <[email protected]> wrote: > > perhaps we could borrow a solution from other large/popular projects > operated on GitHub (yes, Elasticsearch and OpenSearch are in my mind). > > FWIW Elasticsearch uses a separate, issue only, private repo with limited > developer access for security issues. I have no idea how feasible that > would be for an ASF project. One thing I like about this is the tight cross > linking of GitHub issues across projects. So if a security issue is opened, > any relevant public issues can be referred to on it. Then the developers > who have access to the security issues can see the back links on the public > issues. > > On Fri, May 6, 2022 at 22:36 Tomoko Uchida <[email protected]> > wrote: > >> Thanks Gus, for providing the clear pros/cons list and posing an >> objection. I welcome constructive criticism that strengthens our discussion. >> >> Among the informative list, I'd highlight a new perspective I haven't >> seen so far (and honestly, I haven't considered): Security issues that are >> visible to PMC only. >> GitHub-inclined people (including me) would need to answer or find >> solutions for it if it's an inevitable feature for Lucene. As an obvious >> answer, we'll be able to continue to use Jira for such sensitive issues; >> but there could be more sophisticated/integrated ways for that? >> I'm not knowledgeable about current access control for Jira issues. Does >> anyone among the PMC members have an idea - or perhaps we could borrow a >> solution from other large/popular projects operated on GitHub (yes, >> Elasticsearch and OpenSearch are in my mind). >> >> As for accepting contributions (patches) from developers who don't use >> GitHub for some reason, I think we MUST support contribution paths that do >> not rely on GitHub PR, and I suppose every committer agrees with me on that. >> >> Tomoko >> >> >> 2022年5月7日(土) 6:46 Gus Heck <[email protected]>: >> >>> I think both tools have their merits and drawbacks >>> >>> What I like about Jira: >>> >>> - It has ample room and configuration for issue metadata and >>> customizable workflows and in general a deep feature set >>> - It has user roles, PMC members can see security issues that are >>> hidden from the world... >>> - I've used it for almost 20 years so It's familiar to me. >>> - It's hosted at the ASF by the ASF so nobody but the ASF can >>> determine access or hold it hostage (I think, correct me if I'm wrong >>> and we're now using atlassian cloud versions). >>> >>> What Ii do not like about Jira >>> >>> - They have had LONG standing issues with text and visual mode not >>> round-tripping (switching between them alters the text and often destroys >>> formatting) which is something even cheap blogging software usually gets >>> right.... this is EXTREMELY FRUSTRATING at times where the proper name of >>> something in code includes an underscore. Especially bad is the fact that >>> the do provide a way to escape things like underscores but the transition >>> between visual and text destroys that escaping, making it useless, and if >>> you carefully set up the escapes in text mode, one small edit by someone >>> else (perhaps fixing a typo) in visual mode destroys all your hard work! >>> GRRRR... And of course text mode is sometimes hard to predict so working >>> in >>> text mode with any non-trivial formatting that you may wind up re-editing >>> several times which at apache sends multiple emails to the list... >>> usability nightmare. >>> - They switched to a default search result layout that wasn't a >>> sortable table/list. This irritates me because I never want to randomly >>> fill 70% of the screen with the top hit on a search and have almost no >>> info >>> about all the other results. Typically I want to immediately sort by >>> issue >>> number to find recent issues (or older issues depending). Even if text >>> relevancy is the important thing in my search, assuming the top hit is >>> what >>> I want is poor. >>> - By default searches typed in the easily accessed search box run >>> against every project so then the very first thing I have to do is re-run >>> with a project filter. Maintaining a project context would be very >>> helpful. >>> - UI can become cumbersome for filtering on issue fields with many >>> values (typeahead search presumes you know the name to start with). >>> - Sometimes slow. >>> >>> What I like about Github >>> >>> - It fixes the first and third issue I don't like about jira (edit >>> round trip and typically has a project context). >>> - UI updates without explicit refresh >>> - Generally nice look and feel >>> - Integration of github actions, pull requests, review, and code >>> repository is excellent. >>> - Closing issues via commit message is nice for small projects... >>> >>> What I don't like about github. >>> >>> - Very limited and no custom issue metadata >>> - arbitrary file attachments are not supported. Notably .patch is >>> not included in their list (GIF, JPEG, JPG, MOV, MP4, PNG, SVG, CSV, >>> DOCX, >>> FODG, FODP, FODS, FODT, GZ, LOG, MD, ODF, ODG, ODP, ODS, ODT, PDF, PPTX, >>> TXT, XLS, XLSX or ZIP). >>> - Search interface for issues is the equivalent of the Jira JQL >>> search line, and requires learning their syntax for anything but the most >>> basic, and is:issue must be retained (and wastes space in the small text >>> field) or it suddenly starts finding non-issues items. >>> - No concept of workflow (without add/on or plugins). >>> - Closing issues via commit message is not good where you would want >>> to ensure review or have any sort of workflow >>> - It's owned by Microsoft, which while MUCH improved in recent years >>> has a horrible dark, evil past WRT open source and standards. Above >>> allegations regarding political banning of individuals is also very >>> troubling and unfortunately, increasingly relevant in the current global >>> political landscape. >>> >>> From the lucene perspective I see some things we have now in Jira that I >>> don't see a way to maintain in github >>> >>> - Security issues that are visible to PMC only (more common for >>> solr, but perhaps needed for lucene sometimes as well) >>> - Patch review based on an attached patch. >>> - Accepting patch files instead of pull requests... >>> - Contribution by folks who for some reason cannot use github >>> (either blocked by work or github politics or, unwilling to accept >>> githubs >>> terms/privacy etc.) >>> - Document with each issue the Affected version and the fixed >>> version. >>> - While one can create arbitrary labels, they are not segregated >>> into fields so we would have to put up with what is effectively a single >>> field for priority, component, and resolution >>> - No way to enforce that a resolution label is applied to the issue. >>> >>> I feel that Github issues are simply lacking in depth and riding along >>> on the virtue of their integrations. I feel like their issue tracking >>> implementation is a lower priority sideline to their code repository (so >>> they can say they have it). On the flip side Jira has become hugely >>> entrenched in the industry and its profits are no-longer tied to innovation >>> or even usability... and it shows. So I am basically dissatisfied with both >>> (for most of the last 20 years I've been known to mutter about writing my >>> own issue tracker... I've not met one that didn't irritate me somehow, >>> though I haven't actually tried yet, because that's a LOT of work ;) ). >>> >>> Given how many things I've listed, it's likely something's wrong or >>> misapprehended, so certainly speak up if I'm just unaware of something in >>> github. >>> >>> In the end I don't feel like the benefits of github are worth giving up >>> the data quality and features that we do actually use in Jira, so I'm -0.9 >>> on moving to github. >>> >>> -Gus >>> >>> >>> On Fri, May 6, 2022 at 11:11 AM Michael McCandless < >>> [email protected]> wrote: >>> >>>> On Thu, May 5, 2022 at 7:56 AM Robert Muir <[email protected]> wrote: >>>> >>>> As far as replies, in github I highlight the part of the thing i want >>>>> to reply to, and press 'r' key on my keyboard. it quotes it and >>>>> everything. Really convenient to me. >>>>> >>>> >>>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard >>>> shortcuts (just type ? to see them all). >>>> >>>> Mike McCandless >>>> >>>> http://blog.mikemccandless.com >>>> >>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >> -- Marcus Eagan
