On the suggestion of private security only repo in another mail... that seems to mean security issues can never be made public? Presently we have a culture of openness where once the issue is resolved and a fix release we share the discussion. I think that's good since it can then lead security researchers or others to test our fix better and users can better understand why we had to remove something or whatever.
responses inline On Sun, May 8, 2022 at 11:51 PM Marcus Eagan <[email protected]> wrote: > 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. > > Binding votes are not the only important votes, as Tomoko pointed out. > 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. > I don't disagree, and I acknowledge that the recent trend is much improved, but It's a lever by which an external company motivated by profit can disrupt us if it happens to be in their interest. (besides profit, there could be political motives etc, Imagine prominent pmc members expose a flaw that really hurts them or sign some sort of open letter in favor of a political candidate that explicitly wants to target them with antitrust laws... not that happens anymore in the US but nevermind... ). I have a bias for the ASF and its projects to be self-sufficient where feasible, and while loss of donations would be an issue regardless, that would have to be at the ASF level and couldn't target specific projects or individuals making it far less attractive. One can argue that the irritations in Jira are making it infeasible, but that's my bias. > >> - 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>. > Hmm those are labels on PR's not issues. Github does not have an issue/pr direct linking Which reminds me I don't think there's a way to link issues such as "this one blocks that one" or "This one is related to that one", etc. > > >> - 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. > It seems that an issue template would put this information in a comment where it's not filterable, and would need to be maintained. There does seem to be an edit history but is there a label history? In Jira basically any action on the issue is auditable. Imagine someone registers an account and does something malicious (say someone who didn't like us went and removed labels from a ton of issues? how would we know who, and what labels to put back?). Hard to imagine perhaps, but the internet is large and contains a large number of weirdos... > > 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. > If we as a group decide to drop support for them, that's a possible decision. It might need to precede the move to GitHub. > , 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. > Oh yes. Did you note my all caps words ;) I'm in no way suggesting that Jira is particularly friendly to use. It's particularly frustrating that half the things I listed look like they should be relatively easy to fix and in one case they did it to themselves for no reason I can fathom. Context and performance really being harder (context would take some careful design so that the users who want to work across projects still can, and really users like me would want a 2 project context...). I suspect however that actions can't overcome the fact that Github doesn't store distinct fields so unless we have some way of pulling data out of issue comments and making it searchable, under separate fields, there will be gaps. It's been a long time since I've tried to look around in the issue tracker space. Are there 3rd options that might be easier to use, under our direct control and perhaps easier to influence. I've not looked at it, what do we know about https://jackrabbit.apache.org/jcr/issue-tracker.html ? Would have a nice ASF using it's own software angle...
