I don't have a strong opinion on migrating from Jira to GitHub Issues. I would prefer GitHub Issues only for its better integration and because new users that reach from the GitHub repository could be confused to not find the `Issues` tabs (most of the GitHub projects use it).
Also GitHub Issues has a good REST interface, I'm using it in GithubIssueManager[1]. @Justin Bertram <jbert...@apache.org> thanks the detailed doc!!! [1] https://github.com/brusdev/downstream-updater/blob/main/src/main/java/dev/brus/downstream/updater/issue/GithubIssueManager.java On Fri, 5 Apr 2024 at 17:41, Clebert Suconic <clebert.suco...@gmail.com> wrote: > I would prefer to keep JIRA for their REST interface. > > Also: one thing to notice is the possibility of using private comments > in JIRA. Say you ever have a security issue. I think you can have PMC > private comments on JIRAs. I'm not sure you have the same in github > issues. > > > I didn't see a note about private comments on Justin's detailed doc > (nice Doc BTW), but the private comments may be handy on handling > sensitive issues. > > On Fri, Apr 5, 2024 at 5:19 AM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > > The 'track version as Project' thing is interesting, though kinda > > further underscores the limitations of Milestones which are really the > > main surfaced way of handling versions. > > > > I'll bet some folks on the 'users' side of things looking at released > > issues later would even miss that you are doing that (I would), since > > Projects are kinda separate and get even further hidden away upon > > completion; closed Projects are hidden/collapsed in the Issue/PR view > > on expectations they are no longer 'interesting', requiring you to > > spot that and expand the closed-projects view on each Issue/PR to see > > the Project later. Which to be fair I think is actually decent > > behaviour in general for their main use cases, since they aren't > > really aimed to be used as versions but more for using the 'swimlane' > > etc views given for managing/planning overall outstanding tasks to a > > point of completion and will then most typically be > > forgotten/less-interesting detail. > > > > On Thu, 4 Apr 2024 at 22:52, Christopher Shannon > > <christopher.l.shan...@gmail.com> wrote: > > > > > > I am also on the Accumulo PMC and on that project we use Github issues > > > and no longer use Jira. This switch was made before my time so I'm not > > > sure of the reasoning. Personally, I don't really care too much either > > > way as I've used both but I will just point out 2 things from my > > > experience with it. > > > > > > 1) For version tracking, we use projects and not milestones. I don't > > > know if this is the best way to do things but that's what we have been > > > using and seems to work ok as you can list multiple projects > > > (versions) for an Issue or PR: > > > https://github.com/apache/accumulo/projects?type=classic > > > > > > 2) Robbie's point about whether or not Issues get opened is a really > > > good point and something that is not consistent at all in Accumulo. > > > What I have found is it is all over the place. In some cases people > > > just open PRs and essentially are self documenting issues with the > > > fix. In other cases people open up issues and then open up PRs. It > > > does get confusing sometimes since they share the same numbering and > > > name space. It may make sense to try and establish some guidelines if > > > we go with Github Issues just so we are consistent about it. > > > > > > On Thu, Apr 4, 2024 at 2:40 PM Matt Pavlovich <mattr...@gmail.com> > wrote: > > > > > > > > > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell < > robbie.gemm...@gmail.com> wrote: > > > > > > > > > > To the later point around Discussions, I do think enabling those > could > > > > > be good either way since, just like with Jira, people will often > > > > > create Issues to ask questions rather than e.g mail a mailing list. > > > > > They might use a Discussion instead though. > > > > > > > > +1 agree that having discussions enabled would be an upgrade for > users, big improvement over mailing lists. > > > > > > > > > On Tue, 2 Apr 2024 at 20:52, Justin Bertram <jbert...@apache.org> > wrote: > > > > >> > > > > >> There's been a few threads about this general subject, but most > have > > > > >> concentrated on Classic in particular. I think it's worth > discussing > > > > >> migration of ActiveMQ as a whole and diving a bit deeper into the > details > > > > >> of why a migration makes (or doesn't make) sense and what the > challenges > > > > >> may be. > > > > >> > > > > >> To this end I've put together this document [1]. I hope it will > be of > > > > >> service to the community as we consider this option. > > > > >> > > > > >> > > > > >> Justin > > > > >> > > > > >> [1] > > > > >> > https://github.com/jbertram/activemq-website/wiki/Apache-ActiveMQ-GitHub-Issues-Migration-Review > > > > > > > > -- > Clebert Suconic >
