[DISCUSS] Migrate from Jira to GitHub Issues
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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
This is a good summary Justin. As someone who mostly follows issues these days-as opposed to contributing-a few things to add, having used both to manage work: * Github has "projects" which allow you to organize tasks across repos -- which in some ways is helpful, but you have to know to look for the projects * Github milestones are a bit weird, and not as intuitive as target/fix versions, but they suffice -- as Justin points out, deciding how to use those, and reference issues/releases is important * The two tools are mostly comparable with some drawbacks to either: github is about 3 quarters as mature as Jira in many ways IMO, but if it saves the PMC time, that's a big draw. * I agree that the intent of making everything more approachable by using Github is a worthwhile goal, and probably a likely result -- especially if releases are being tagged + documented in the project * Seeing a repo with a ton of issues on github isn't really the best visual experience, as the github UI isn't super clear, so probably setting up/linking some project views would be the way to go On Tue, 2 Apr 2024, at 12:52 PM, Justin Bertram 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hi Justin Fantastic work and great summary ! I do a quick pass, I will do a more detailed read. Thanks ! Regards JB On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
I read through Justin's document up to the section "Why Use GitHub Issues?" and have questions. When users want Jira access, do they use an Apache account, or can it be any account? Or are we just creating jira-specific accounts for these users? Do they have / need-to-have an ICLA signed and on-file? It seems to me the real issue at heart here is avoiding spam, and using authenticated users as a means to that end. So, I'm trying to understand whether that's feasible with Apache Jira. Art P.S. Nice write-up Justin - thank you! On Wed, Apr 3, 2024 at 2:16 AM Jean-Baptiste Onofré wrote: > > Hi Justin > > Fantastic work and great summary ! > > I do a quick pass, I will do a more detailed read. > > Thanks ! > Regards > JB > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
> When users want Jira access, do they use an Apache account, or can it be any account? Folks who have an Apache account (e.g. committers, PMC members, etc.) automatically have access to the ASF Jira instance. > Or are we just creating jira-specific accounts for these users? If you don't have an Apache account and you want to create a Jira, for example, then you must request a Jira account. This is an account specifically for the ASF Jira instance. Lots of websites employ OAuth so that you can, for example, use your Google account or Facebook account to access their services. That's not true of ASF Jira. You must have a specific ASF Jira account. > Do they have / need-to-have an ICLA signed and on-file? No. > It seems to me the real issue at heart here is avoiding spam, and using authenticated users as a means to that end. So, I'm trying to understand whether that's feasible with Apache Jira. As far as I know ASF Infra has _always_ required an account to create Jiras, etc. However, that requirement still hasn't been sufficient to prevent spam - even with a captcha for creating an account. Therefore, the PMC now has to approve Jira account requests. Justin On Wed, Apr 3, 2024 at 11:10 AM Arthur Naseef wrote: > I read through Justin's document up to the section "Why Use GitHub > Issues?" and have questions. > > When users want Jira access, do they use an Apache account, or can it > be any account? Or are we just creating jira-specific accounts for > these users? Do they have / need-to-have an ICLA signed and on-file? > > It seems to me the real issue at heart here is avoiding spam, and > using authenticated users as a means to that end. So, I'm trying to > understand whether that's feasible with Apache Jira. > > Art > > P.S. Nice write-up Justin - thank you! > > On Wed, Apr 3, 2024 at 2:16 AM Jean-Baptiste Onofré > wrote: > > > > Hi Justin > > > > Fantastic work and great summary ! > > > > I do a quick pass, I will do a more detailed read. > > > > Thanks ! > > Regards > > JB > > > > On Tue, Apr 2, 2024 at 9:52 PM Justin Bertram > 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 > >
Re: [DISCUSS] Migrate from Jira to GitHub Issues
A big thank you to Justin for his effort to research and document this topic and the options available! This info is very helpful to better understand the scope of the situation. Justin mentioned that he spends about 20 minutes per month on Jira account approval, so there's not a tremendous time savings by off-loading issue management to GitHub. Are there any other costs that we should consider in terms of time? In fact, if we were to make this change, it might actually require a lot more toil from the PMC to make the changes and manage the situation in a new manner as well as from the users to understand the new setup. While I was one of the folks who angled toward a move from Jira to GitHub for issue management, I'm not necessarily convinced that such a change will result in the best user experience as well as decrease the work the PMC does to manage Jira account requests. I was under the impression that the Jira account management aspect cost more time than it does. Bruce
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hello @dev- I argue that we are effectively already using GitHub for issues, JIRA is just getting a back-port sync of the discussion. The reality is that code-change discussions are occurring on the PRs, not in JIRA or mailing lists-- and that makes sense. It is far easier to have a discussion while referencing the line of code and providing a checklist of issues to resolve to the committer. The GitHub-to-JIRA synchronization is noisy and generates a lot of text in the JIRA comments that aren't really legible. The JIRA issue-to-PR process is cumbersome, there's now even a "NO-JIRA" process to work around that reality -- and that has led to back-and-forth on certain issues that start NO-JIRA, and then need to have a JIRA created and vice-versa. Issues: - Customizable templates that can enforce policy to reduce back-and-forth with in-experienced issue submitters. Release notes: - Simple generation, template-izable and ability to customize at release time (ie to remove any NO-JIRA type things that don't need to be in release notes) In terms of migration complexity, I think the numbers make the migration effort look larger than the actual reality on the ground. We are really talking about 2 active repos (activemq & artemis) and 1 periodically updated repo (nms). Migration can be over time and on a project-by-project or repo-by-repo basis. The majority of total repo count are NMS related, and there is an argument that those should be combined to a single repo for easier release. Using the top-level NMS project for issues and labels for sub-projects would be suitable for a low-traffic module such as that. The activemq-cli-tools can move/migrate into the main ActiveMQ repo, its a simple tool and it makes sense to include that function in the distribution. We've transitioned to a new era in software development, and we should move to the tools that are more readily used by dev-users in this era. That is currently GitHub. GitHub is a better toolkit for streamlining the management of the project and developing community engagement. Thank you for attending my TED talk, Matt Pavlovich > On Apr 2, 2024, at 2:52 PM, Justin Bertram 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
On Wed, 3 Apr 2024 at 21:14, Matt Pavlovich wrote: > > Hello @dev- > > I argue that we are effectively already using GitHub for issues, JIRA is just > getting a back-port sync of the discussion. The reality is that code-change > discussions are occurring on the PRs, not in JIRA or mailing lists-- and that > makes sense. It is far easier to have a discussion while referencing the line > of code and providing a checklist of issues to resolve to the committer. The > GitHub-to-JIRA synchronization is noisy and generates a lot of text in the > JIRA comments that aren't really legible. > That argument seems centered on the code discussion on a PR being the main interesting bit of a Jira / Issue. For me, and I expect a lot of users, I'd say it is often rather more the initial description/report for e.g what a bug is, the collating of the [often multiple and separate] commits made to fix it, and the release version tracking, that tend to be as much or more interesting aspect of a Jira than what are often just 'working thoughts' comments on a PR to get from the initial proposed change to whatever is pushed. For that stuff, indeed the PR is often a better place for to see that in-context. This would be true for me, and again I expect a lot of users, regardless whether it was an Issue or a Jira being used to track things (or at least, would be supposing people adequately xref commits/Issues to make up for the limitations in Issues/PRs use of Milestones to track versions...i.e they can only point to 1). (On the comments, the Github updates on our Jira's go in as 'work log' entries rather than regular comments, so they actually aren't in the way normally) > The JIRA issue-to-PR process is cumbersome, there's now even a "NO-JIRA" > process to work around that reality -- and that has led to back-and-forth on > certain issues that start NO-JIRA, and then need to have a JIRA created and > vice-versa. > Thats been happening since before PRs were an option, started due to direct commit/push behaviour where PRs wouldnt have existed anyway, and could essentially still happen with Issues too depending on what approach were to be decided on for Issue <-> PR relationship, i.e whether an issue is always needed or if a PR alone is sufficient. It was me that initially coined the NO-JIRA thing over at Qpid > 10 years ago, as an escape for a commit hook that required a Jira ref, to help prod people that were not creating Jiras for actually-quite-important/notable changes out of pure laziness, and make it clear it wasnt then 'just an oversight' it was omitted. Alas, since the ASF operated on a single foundation-wide Subversion repository at the time, and due to the way the hook had to actually operate as a result, it was found to be too slow to justify applying it to every commit at the ASF just for one/some projects benefit to prod people to be less lazy, and so that side ultimately didnt happen. The commit message bit stuck around though, migrated, and has over time become just as abused as reference'less commit logs were. Doh :) The equivalent while having Issues instead of Jira's would center around deciding if we wanted to always have an Issue for a given change even if a PR is being raised, given that whilst they do share a number space they are still defaulted to mostly being distinct things in the UI and URLs. I expect many people making changes often won't bother to raise an Issue, just the PR (or again, sometimes neither). Most people not interested in making changes (i.e most user reports) will of course just raise an Issue alone. Often people will raise a non-xref'd PR for the same thing even though the Issue exists, since they didnt raise or notice that Issue themselves originally (same happen with Jira's too). This is an annoyance I find with Issues and PRs, sharing a number space and being treated similarly by many, while still being considered quite separate especially in the UI and URls (the main annoyance being Milestone handling, where you can only have 1, which I find it means most projects just have useless or no release notes for their non-latest releases as a result, and you really just need to look at the tags and commits to see what you need) > Issues: > - Customizable templates that can enforce policy to reduce back-and-forth > with in-experienced issue submitters. I find those templates as much just increase the number of Issues littered with templates not actually filled in. > > Release notes: > - Simple generation, template-izable and ability to customize at release > time (ie to remove any NO-JIRA type things that don't need to be in release > notes) > > In terms of migration complexity, I think the numbers make the migration > effort look larger than the actual reality on the ground. We are really > talking about 2 active repos (activemq & artemis) and 1 periodically updated > repo (nms). > > Migration can be over time and on a project-by-project or repo-by-repo basis. > The
Re: [DISCUSS] Migrate from Jira to GitHub Issues
I prefer Jira for issue tracking, I think it's better at it, particularly for cases like 5.x / 6.x having multiple active release streams with lots of backports, given the limitations of Milestone handling and how people tend to treat xref'ing to fully compensate for that (i.e they often dont bother). I would be fine with adopting Issues too though, I use Issues plenty elsewhere where it's enabled by default and the only option anyway hehe. I expect most users reporting things would prefer Issues at this point, especially anyone intende to raise a PR, and most particularly all the folks without Jira accounts already (of course, I also think many of those asking for accounts dont actually need one; see Discussions note at end). I dont actually think every component needs to use the exact same labels etc. People are already used to just about every other GitHub repo they encounter at this point which uses Issue having their own labels. For me, the labels just need to make sense in themselves. Though the default ones are simple, so I'd be fine with them, which would then just happen to be consistent. It's not clear to me anyone proposing to move to Issues actually intended thus far to migrate any of the [open] issues from Jira to Github Issues, so much as just start using Github Issues and thus effectively 'clearing the cruft' by leaving it where it is, then raising new issues going forward? 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. On Tue, 2 Apr 2024 at 20:52, Justin Bertram 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
> On Apr 4, 2024, at 1:26 PM, Robbie Gemmell 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 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
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 wrote: > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell 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 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 >
Re: [DISCUSS] Migrate from Jira to GitHub Issues
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 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 wrote: > > > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell > > > 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 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 > >
Re: [DISCUSS] Migrate from Jira to GitHub Issues
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 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 > 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 wrote: > > > > > > > > > > On Apr 4, 2024, at 1:26 PM, Robbie Gemmell > > > > 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 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
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 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 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 > 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 > > 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 > 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 > 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 >
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Is there a private comment capability on GitHub? To me that’s a breaking deal feature and I have never seen it. On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino < bruscin...@gmail.com> wrote: > 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 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 > 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 > > 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 > > > 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 > > 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 > > > 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 > > > >
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hi, Thanks again Justin for the detailed doc, that's a great one ! I understand the gaps you identified and agree with your points. Regarding the comments and feedback, I think we don't have a strong enough consensus for this move. So I would propose to stay with Jira for now. Thoughts ? Regards JB On Fri, Apr 5, 2024 at 6:47 PM Clebert Suconic wrote: > > Is there a private comment capability on GitHub? To me that’s a breaking > deal feature and I have never seen it. > > On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino < > bruscin...@gmail.com> wrote: > > > 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 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 > > 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 > > > 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 > > > > 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 > > > 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. > > > > > > > > > >
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Whilst Jira can certainly do that, I dont believe we have ever used it in that fashion here, and so I dont see that it could be considered a break either way. Also, the process of e.g privately reporting security issues wouldnt change in any event, it would remain as it is now (and is detailed on each github repository already due to some org level defaults). On Fri, 5 Apr 2024 at 17:48, Clebert Suconic wrote: > > Is there a private comment capability on GitHub? To me that’s a breaking > deal feature and I have never seen it. > > On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino < > bruscin...@gmail.com> wrote: > > > 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 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 > > 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 > > > 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 > > > > 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 > > > 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,
Re: [DISCUSS] Migrate from Jira to GitHub Issues
On the lack of Issues tab, though it doesnt seem to have been too much of an issue so far, we could certainly improve that by ensuring each repo README always covers how to raise things (or just links to the website page that covers it; I think some repos already do). Plus, opening Discussions again might be a suitable alternative for many of the things that get raised as issues but are actually just questions. On Fri, 5 Apr 2024 at 17:15, Domenico Francesco Bruscino wrote: > > 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 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 > 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 > > 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 > > > 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 > > 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 > > 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hi Clebert-
How widely used are private comments today?
I ran a search and I do not see any private comments in use with the ActiveMQ
project. I tried searching the ARTEMIS project, perhaps I got the JQL incorrect?
project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
project = ARTEMIS AND issueFunction in commented(“role PMC")
An available solution would be to use a private GH repo would secure all the
items — code, issues, etc.. from unprivileged users. A PMC-only repo could have
issues-only or discussion-only for CVE discussions.
I think private comment is a wonky concept, as it is easy to get that toggled
incorrectly. I think it is better to restrict access to a secured area vs
trying to feather comments.
Thanks,
Matt
> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
> wrote:
>
> Is there a private comment capability on GitHub? To me that’s a breaking
> deal feature and I have never seen it.
>
> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> bruscin...@gmail.com> wrote:
>
>> 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 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
>> 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
>>> 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
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
>>> 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
Re: [DISCUSS] Migrate from Jira to GitHub Issues
I haven’t used it on the Apache Jira but I use private comments all the
time on my company JIRA for things that would be related to security and
injeritently private.
I thought we could eventually start using a feature like that and I thought
it would be a nice feature to keep. But if everybody think we should keep
everything open and just use private list for private comments that’s fine.
On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
> Hi Clebert-
>
> How widely used are private comments today?
>
> I ran a search and I do not see any private comments in use with the
> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> JQL incorrect?
>
> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> project = ARTEMIS AND issueFunction in commented(“role PMC")
>
> An available solution would be to use a private GH repo would secure all
> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> could have issues-only or discussion-only for CVE discussions.
>
> I think private comment is a wonky concept, as it is easy to get that
> toggled incorrectly. I think it is better to restrict access to a secured
> area vs trying to feather comments.
>
> Thanks,
> Matt
>
> > On Apr 5, 2024, at 11:47 AM, Clebert Suconic
> wrote:
> >
> > Is there a private comment capability on GitHub? To me that’s a breaking
> > deal feature and I have never seen it.
> >
> > On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> > bruscin...@gmail.com> wrote:
> >
> >> 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 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 >
> >> 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
> 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 op
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Got it, that makes sense. I think we could achieve the same effect w/ a private
repo (ie "activmeq-pmc”) and enable what ever product features makes sense—
issues, discussion, etc.
I agree, moving off of mailing list would be beneficial for certain discussions
(esp security reports) b/c of things like attachments, links, etc often become
a security challenge w/ email.
-Matt
> On Apr 5, 2024, at 6:58 PM, Clebert Suconic wrote:
>
> I haven’t used it on the Apache Jira but I use private comments all the
> time on my company JIRA for things that would be related to security and
> injeritently private.
>
> I thought we could eventually start using a feature like that and I thought
> it would be a nice feature to keep. But if everybody think we should keep
> everything open and just use private list for private comments that’s fine.
>
> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
>
>> Hi Clebert-
>>
>> How widely used are private comments today?
>>
>> I ran a search and I do not see any private comments in use with the
>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
>> JQL incorrect?
>>
>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>>
>> An available solution would be to use a private GH repo would secure all
>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
>> could have issues-only or discussion-only for CVE discussions.
>>
>> I think private comment is a wonky concept, as it is easy to get that
>> toggled incorrectly. I think it is better to restrict access to a secured
>> area vs trying to feather comments.
>>
>> Thanks,
>> Matt
>>
>>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
>> wrote:
>>>
>>> Is there a private comment capability on GitHub? To me that’s a breaking
>>> deal feature and I have never seen it.
>>>
>>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>>> bruscin...@gmail.com> wrote:
>>>
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 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 >>
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
>> 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
>>>
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Just a reminder: even if we use GitHub Discussions, we should always
send a pointer on the mailing list. As we say at Apache: "if it
doesn't occur on the mailing list, it never occurred".
Thanks
Regards
JB
On Mon, Apr 8, 2024 at 6:27 PM Matt Pavlovich wrote:
>
> Got it, that makes sense. I think we could achieve the same effect w/ a
> private repo (ie "activmeq-pmc”) and enable what ever product features makes
> sense— issues, discussion, etc.
>
> I agree, moving off of mailing list would be beneficial for certain
> discussions (esp security reports) b/c of things like attachments, links, etc
> often become a security challenge w/ email.
>
> -Matt
>
> > On Apr 5, 2024, at 6:58 PM, Clebert Suconic
> > wrote:
> >
> > I haven’t used it on the Apache Jira but I use private comments all the
> > time on my company JIRA for things that would be related to security and
> > injeritently private.
> >
> > I thought we could eventually start using a feature like that and I thought
> > it would be a nice feature to keep. But if everybody think we should keep
> > everything open and just use private list for private comments that’s fine.
> >
> > On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
> >
> >> Hi Clebert-
> >>
> >> How widely used are private comments today?
> >>
> >> I ran a search and I do not see any private comments in use with the
> >> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> >> JQL incorrect?
> >>
> >> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> >> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>
> >> An available solution would be to use a private GH repo would secure all
> >> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> >> could have issues-only or discussion-only for CVE discussions.
> >>
> >> I think private comment is a wonky concept, as it is easy to get that
> >> toggled incorrectly. I think it is better to restrict access to a secured
> >> area vs trying to feather comments.
> >>
> >> Thanks,
> >> Matt
> >>
> >>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
> >> wrote:
> >>>
> >>> Is there a private comment capability on GitHub? To me that’s a breaking
> >>> deal feature and I have never seen it.
> >>>
> >>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>> bruscin...@gmail.com> wrote:
> >>>
> 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 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 >>>
> 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
> >> wrote:
> >>>
> >>> I am also on the Accumulo PMC and on that project we use Github
>
Re: [DISCUSS] Migrate from Jira to GitHub Issues
The security reporting/followup follow the process/requirements set
out by security@ so we cant really just change things around
that...though if there ideas, then perhaps they can be discussed with
them toward being generally applicable.
I believe there are private subversion repo areas for PMCs (never use
it though), not sure whether there are facilities yet for PMC git
repos.
On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote:
>
> Got it, that makes sense. I think we could achieve the same effect w/ a
> private repo (ie "activmeq-pmc”) and enable what ever product features makes
> sense— issues, discussion, etc.
>
> I agree, moving off of mailing list would be beneficial for certain
> discussions (esp security reports) b/c of things like attachments, links, etc
> often become a security challenge w/ email.
>
> -Matt
>
> > On Apr 5, 2024, at 6:58 PM, Clebert Suconic
> > wrote:
> >
> > I haven’t used it on the Apache Jira but I use private comments all the
> > time on my company JIRA for things that would be related to security and
> > injeritently private.
> >
> > I thought we could eventually start using a feature like that and I thought
> > it would be a nice feature to keep. But if everybody think we should keep
> > everything open and just use private list for private comments that’s fine.
> >
> > On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
> >
> >> Hi Clebert-
> >>
> >> How widely used are private comments today?
> >>
> >> I ran a search and I do not see any private comments in use with the
> >> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> >> JQL incorrect?
> >>
> >> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> >> project = ARTEMIS AND issueFunction in commented(“role PMC")
> >>
> >> An available solution would be to use a private GH repo would secure all
> >> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> >> could have issues-only or discussion-only for CVE discussions.
> >>
> >> I think private comment is a wonky concept, as it is easy to get that
> >> toggled incorrectly. I think it is better to restrict access to a secured
> >> area vs trying to feather comments.
> >>
> >> Thanks,
> >> Matt
> >>
> >>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
> >> wrote:
> >>>
> >>> Is there a private comment capability on GitHub? To me that’s a breaking
> >>> deal feature and I have never seen it.
> >>>
> >>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >>> bruscin...@gmail.com> wrote:
> >>>
> 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 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 >>>
> 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.
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Robbie-
One option with GH issues is we can have them prompted with a ’type’ (for
example, an issue or security report). Security report workflow could take them
to the readme with email link to direct users to the mailing list and
(hopefully) getting better adherence to the requested security process.
-Matt
> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell wrote:
>
> The security reporting/followup follow the process/requirements set
> out by security@ so we cant really just change things around
> that...though if there ideas, then perhaps they can be discussed with
> them toward being generally applicable.
>
> I believe there are private subversion repo areas for PMCs (never use
> it though), not sure whether there are facilities yet for PMC git
> repos.
>
> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote:
>>
>> Got it, that makes sense. I think we could achieve the same effect w/ a
>> private repo (ie "activmeq-pmc”) and enable what ever product features makes
>> sense— issues, discussion, etc.
>>
>> I agree, moving off of mailing list would be beneficial for certain
>> discussions (esp security reports) b/c of things like attachments, links,
>> etc often become a security challenge w/ email.
>>
>> -Matt
>>
>>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic
>>> wrote:
>>>
>>> I haven’t used it on the Apache Jira but I use private comments all the
>>> time on my company JIRA for things that would be related to security and
>>> injeritently private.
>>>
>>> I thought we could eventually start using a feature like that and I thought
>>> it would be a nice feature to keep. But if everybody think we should keep
>>> everything open and just use private list for private comments that’s fine.
>>>
>>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
>>>
Hi Clebert-
How widely used are private comments today?
I ran a search and I do not see any private comments in use with the
ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
JQL incorrect?
project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
project = ARTEMIS AND issueFunction in commented(“role PMC")
An available solution would be to use a private GH repo would secure all
the items — code, issues, etc.. from unprivileged users. A PMC-only repo
could have issues-only or discussion-only for CVE discussions.
I think private comment is a wonky concept, as it is easy to get that
toggled incorrectly. I think it is better to restrict access to a secured
area vs trying to feather comments.
Thanks,
Matt
> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
wrote:
>
> Is there a private comment capability on GitHub? To me that’s a breaking
> deal feature and I have never seen it.
>
> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> bruscin...@gmail.com> wrote:
>
>> 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 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
>> 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 v
Re: [DISCUSS] Migrate from Jira to GitHub Issues
@dev-
I’m summarizing the good points here and starting [PROPOSAL] thread to draft up
potential next steps.
Thanks,
Matt
> On Apr 16, 2024, at 9:58 AM, Matt Pavlovich wrote:
>
> Robbie-
>
> One option with GH issues is we can have them prompted with a ’type’ (for
> example, an issue or security report). Security report workflow could take
> them to the readme with email link to direct users to the mailing list and
> (hopefully) getting better adherence to the requested security process.
>
> -Matt
>
>> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell wrote:
>>
>> The security reporting/followup follow the process/requirements set
>> out by security@ so we cant really just change things around
>> that...though if there ideas, then perhaps they can be discussed with
>> them toward being generally applicable.
>>
>> I believe there are private subversion repo areas for PMCs (never use
>> it though), not sure whether there are facilities yet for PMC git
>> repos.
>>
>> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote:
>>>
>>> Got it, that makes sense. I think we could achieve the same effect w/ a
>>> private repo (ie "activmeq-pmc”) and enable what ever product features
>>> makes sense— issues, discussion, etc.
>>>
>>> I agree, moving off of mailing list would be beneficial for certain
>>> discussions (esp security reports) b/c of things like attachments, links,
>>> etc often become a security challenge w/ email.
>>>
>>> -Matt
>>>
On Apr 5, 2024, at 6:58 PM, Clebert Suconic
wrote:
I haven’t used it on the Apache Jira but I use private comments all the
time on my company JIRA for things that would be related to security and
injeritently private.
I thought we could eventually start using a feature like that and I thought
it would be a nice feature to keep. But if everybody think we should keep
everything open and just use private list for private comments that’s fine.
On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
> Hi Clebert-
>
> How widely used are private comments today?
>
> I ran a search and I do not see any private comments in use with the
> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got the
> JQL incorrect?
>
> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> project = ARTEMIS AND issueFunction in commented(“role PMC")
>
> An available solution would be to use a private GH repo would secure all
> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> could have issues-only or discussion-only for CVE discussions.
>
> I think private comment is a wonky concept, as it is easy to get that
> toggled incorrectly. I think it is better to restrict access to a secured
> area vs trying to feather comments.
>
> Thanks,
> Matt
>
>> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
> wrote:
>>
>> Is there a private comment capability on GitHub? To me that’s a breaking
>> deal feature and I have never seen it.
>>
>> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
>> bruscin...@gmail.com> wrote:
>>
>>> 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 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 >
>>> 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 d
Re: [DISCUSS] Migrate from Jira to GitHub Issues
I am not convinced that we should replace Jira with Github issues. Based on
the info gathered and the discussions thus far, I believe such a change
would cause significant confusion for our users. As noted previously, there
is a significant difference between the purposes for a Jira issue vs.
comments in a PR. These are two completely different artifacts serving
different needs in the process and you cannot replace one with the other.
Bruce
On Tue, Apr 16, 2024 at 9:27 AM Matt Pavlovich wrote:
> @dev-
>
> I’m summarizing the good points here and starting [PROPOSAL] thread to
> draft up potential next steps.
>
> Thanks,
> Matt
>
> > On Apr 16, 2024, at 9:58 AM, Matt Pavlovich wrote:
> >
> > Robbie-
> >
> > One option with GH issues is we can have them prompted with a ’type’
> (for example, an issue or security report). Security report workflow could
> take them to the readme with email link to direct users to the mailing list
> and (hopefully) getting better adherence to the requested security process.
> >
> > -Matt
> >
> >> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell
> wrote:
> >>
> >> The security reporting/followup follow the process/requirements set
> >> out by security@ so we cant really just change things around
> >> that...though if there ideas, then perhaps they can be discussed with
> >> them toward being generally applicable.
> >>
> >> I believe there are private subversion repo areas for PMCs (never use
> >> it though), not sure whether there are facilities yet for PMC git
> >> repos.
> >>
> >> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote:
> >>>
> >>> Got it, that makes sense. I think we could achieve the same effect w/
> a private repo (ie "activmeq-pmc”) and enable what ever product features
> makes sense— issues, discussion, etc.
> >>>
> >>> I agree, moving off of mailing list would be beneficial for certain
> discussions (esp security reports) b/c of things like attachments, links,
> etc often become a security challenge w/ email.
> >>>
> >>> -Matt
> >>>
> On Apr 5, 2024, at 6:58 PM, Clebert Suconic <
> clebert.suco...@gmail.com> wrote:
>
> I haven’t used it on the Apache Jira but I use private comments all
> the
> time on my company JIRA for things that would be related to security
> and
> injeritently private.
>
> I thought we could eventually start using a feature like that and I
> thought
> it would be a nice feature to keep. But if everybody think we should
> keep
> everything open and just use private list for private comments that’s
> fine.
>
> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich
> wrote:
>
> > Hi Clebert-
> >
> > How widely used are private comments today?
> >
> > I ran a search and I do not see any private comments in use with the
> > ActiveMQ project. I tried searching the ARTEMIS project, perhaps I
> got the
> > JQL incorrect?
> >
> > project = ARTEMIS AND issueFunction in commented("group
> activemq-pmc”)
> > project = ARTEMIS AND issueFunction in commented(“role PMC")
> >
> > An available solution would be to use a private GH repo would secure
> all
> > the items — code, issues, etc.. from unprivileged users. A PMC-only
> repo
> > could have issues-only or discussion-only for CVE discussions.
> >
> > I think private comment is a wonky concept, as it is easy to get that
> > toggled incorrectly. I think it is better to restrict access to a
> secured
> > area vs trying to feather comments.
> >
> > Thanks,
> > Matt
> >
> >> On Apr 5, 2024, at 11:47 AM, Clebert Suconic <
> clebert.suco...@gmail.com>
> > wrote:
> >>
> >> Is there a private comment capability on GitHub? To me that’s a
> breaking
> >> deal feature and I have never seen it.
> >>
> >> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >> bruscin...@gmail.com> wrote:
> >>
> >>> 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 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
>
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hi Matt,
Thanks for that.
If I may, I don't see a strong consensus yet about GH Issues. The
other thread you started contains some non accurate points (we should
have clear statements to the community for clarity).
Regards
JB
On Tue, Apr 16, 2024 at 5:26 PM Matt Pavlovich wrote:
>
> @dev-
>
> I’m summarizing the good points here and starting [PROPOSAL] thread to draft
> up potential next steps.
>
> Thanks,
> Matt
>
> > On Apr 16, 2024, at 9:58 AM, Matt Pavlovich wrote:
> >
> > Robbie-
> >
> > One option with GH issues is we can have them prompted with a ’type’ (for
> > example, an issue or security report). Security report workflow could take
> > them to the readme with email link to direct users to the mailing list and
> > (hopefully) getting better adherence to the requested security process.
> >
> > -Matt
> >
> >> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell
> >> wrote:
> >>
> >> The security reporting/followup follow the process/requirements set
> >> out by security@ so we cant really just change things around
> >> that...though if there ideas, then perhaps they can be discussed with
> >> them toward being generally applicable.
> >>
> >> I believe there are private subversion repo areas for PMCs (never use
> >> it though), not sure whether there are facilities yet for PMC git
> >> repos.
> >>
> >> On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote:
> >>>
> >>> Got it, that makes sense. I think we could achieve the same effect w/ a
> >>> private repo (ie "activmeq-pmc”) and enable what ever product features
> >>> makes sense— issues, discussion, etc.
> >>>
> >>> I agree, moving off of mailing list would be beneficial for certain
> >>> discussions (esp security reports) b/c of things like attachments, links,
> >>> etc often become a security challenge w/ email.
> >>>
> >>> -Matt
> >>>
> On Apr 5, 2024, at 6:58 PM, Clebert Suconic
> wrote:
>
> I haven’t used it on the Apache Jira but I use private comments all the
> time on my company JIRA for things that would be related to security and
> injeritently private.
>
> I thought we could eventually start using a feature like that and I
> thought
> it would be a nice feature to keep. But if everybody think we should
> keep
> everything open and just use private list for private comments that’s
> fine.
>
> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
>
> > Hi Clebert-
> >
> > How widely used are private comments today?
> >
> > I ran a search and I do not see any private comments in use with the
> > ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got
> > the
> > JQL incorrect?
> >
> > project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
> > project = ARTEMIS AND issueFunction in commented(“role PMC")
> >
> > An available solution would be to use a private GH repo would secure all
> > the items — code, issues, etc.. from unprivileged users. A PMC-only repo
> > could have issues-only or discussion-only for CVE discussions.
> >
> > I think private comment is a wonky concept, as it is easy to get that
> > toggled incorrectly. I think it is better to restrict access to a
> > secured
> > area vs trying to feather comments.
> >
> > Thanks,
> > Matt
> >
> >> On Apr 5, 2024, at 11:47 AM, Clebert Suconic
> >>
> > wrote:
> >>
> >> Is there a private comment capability on GitHub? To me that’s a
> >> breaking
> >> deal feature and I have never seen it.
> >>
> >> On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
> >> bruscin...@gmail.com> wrote:
> >>
> >>> 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 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
> >>> >>
> >>> 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 det
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hi Bruce- I don’t believe there is any intention to replace issue comments with comments on a PR or vice versa. My point is that the current process of using JIRA for issue discussion isn’t really effective, and doesn’t serve a newer user base that is more familiar with using GitHub vs JIRA. A sizable chunk of discussion about fixes is happening on the PR’s today. Users filing a JIRA do not have the same visibility to the PR discussions there as they would vs if they filed a GH issue that is linked to a PR. The JIRA <-> GH synchronization is wonky and spams the comments with the gitbox commits. With GH issues, the commit and PR work is listed in the issue history timeline, but that information set back and leads to an nicer (imho) navigation of the comments and track what is going on from a standard end-user POV (ie.. non-committer user). Additionally, cross-project work is easier to reference because we can link across open source org repos for PRs and issues. Discussions flow and are referenced much smoother for collaborating with other projects such as Spring, Jetty, etc. Taking the end-user approval workflow off the plate of the PMC is a side-benefit, but the main effect is lowering the barrier to entry for end-users and having a single account (with better transparency of identity) for issues and PR contributors. (GH account age, other GH project contributions, id verification, public keys, etc). Today users in the ActiveMQ community need two accounts to report an issue and provide a PR. This doesn’t seem great to me. In summary moving to GH issues is about: 1. Support for a single identity for issue and/or PR contribution 2. Use more familiar tools for a growing community of community users that are new to ActiveMQ 3. Centralize issue discussion and PR discussion 4. Remove JIRA user approval workflow from the plate of PMC 5. Possibly enabling discussion tools to provide better resource for users to interact with the ActiveMQ community in a more official capacity. Thanks, Matt > On Apr 16, 2024, at 11:28 AM, Bruce Snyder wrote: > > I am not convinced that we should replace Jira with Github issues. Based on > the info gathered and the discussions thus far, I believe such a change > would cause significant confusion for our users. As noted previously, there > is a significant difference between the purposes for a Jira issue vs. > comments in a PR. These are two completely different artifacts serving > different needs in the process and you cannot replace one with the other. > > Bruce > > On Tue, Apr 16, 2024 at 9:27 AM Matt Pavlovich wrote: > >> @dev- >> >> I’m summarizing the good points here and starting [PROPOSAL] thread to >> draft up potential next steps. >> >> Thanks, >> Matt >> >>> On Apr 16, 2024, at 9:58 AM, Matt Pavlovich wrote: >>> >>> Robbie- >>> >>> One option with GH issues is we can have them prompted with a ’type’ >> (for example, an issue or security report). Security report workflow could >> take them to the readme with email link to direct users to the mailing list >> and (hopefully) getting better adherence to the requested security process. >>> >>> -Matt >>> On Apr 8, 2024, at 12:29 PM, Robbie Gemmell >> wrote: The security reporting/followup follow the process/requirements set out by security@ so we cant really just change things around that...though if there ideas, then perhaps they can be discussed with them toward being generally applicable. I believe there are private subversion repo areas for PMCs (never use it though), not sure whether there are facilities yet for PMC git repos. On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote: > > Got it, that makes sense. I think we could achieve the same effect w/ >> a private repo (ie "activmeq-pmc”) and enable what ever product features >> makes sense— issues, discussion, etc. > > I agree, moving off of mailing list would be beneficial for certain >> discussions (esp security reports) b/c of things like attachments, links, >> etc often become a security challenge w/ email. > > -Matt > >> On Apr 5, 2024, at 6:58 PM, Clebert Suconic < >> clebert.suco...@gmail.com> wrote: >> >> I haven’t used it on the Apache Jira but I use private comments all >> the >> time on my company JIRA for things that would be related to security >> and >> injeritently private. >> >> I thought we could eventually start using a feature like that and I >> thought >> it would be a nice feature to keep. But if everybody think we should >> keep >> everything open and just use private list for private comments that’s >> fine. >> >> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich >> wrote: >> >>> Hi Clebert- >>> >>> How widely used are private comments today? >>> >>> I ran a search and I do not see any private comments in use with the >>> ActiveMQ project.
Re: [DISCUSS] Migrate from Jira to GitHub Issues
Hi JB-
Yep, thanks for calling that out. When I indicated ‘security mailing list’ I
should have been more clear to say ’secur...@apache.org’, to remove ambiguity
that I was referring to an ActiveMQ mailing list.
I’ll clean-up points on the Proposal thread.
Thanks!
Matt
> On Apr 16, 2024, at 11:57 AM, Jean-Baptiste Onofré wrote:
>
> Hi Matt,
>
> Thanks for that.
>
> If I may, I don't see a strong consensus yet about GH Issues. The
> other thread you started contains some non accurate points (we should
> have clear statements to the community for clarity).
>
> Regards
> JB
>
> On Tue, Apr 16, 2024 at 5:26 PM Matt Pavlovich wrote:
>>
>> @dev-
>>
>> I’m summarizing the good points here and starting [PROPOSAL] thread to draft
>> up potential next steps.
>>
>> Thanks,
>> Matt
>>
>>> On Apr 16, 2024, at 9:58 AM, Matt Pavlovich wrote:
>>>
>>> Robbie-
>>>
>>> One option with GH issues is we can have them prompted with a ’type’ (for
>>> example, an issue or security report). Security report workflow could take
>>> them to the readme with email link to direct users to the mailing list and
>>> (hopefully) getting better adherence to the requested security process.
>>>
>>> -Matt
>>>
On Apr 8, 2024, at 12:29 PM, Robbie Gemmell
wrote:
The security reporting/followup follow the process/requirements set
out by security@ so we cant really just change things around
that...though if there ideas, then perhaps they can be discussed with
them toward being generally applicable.
I believe there are private subversion repo areas for PMCs (never use
it though), not sure whether there are facilities yet for PMC git
repos.
On Mon, 8 Apr 2024 at 17:27, Matt Pavlovich wrote:
>
> Got it, that makes sense. I think we could achieve the same effect w/ a
> private repo (ie "activmeq-pmc”) and enable what ever product features
> makes sense— issues, discussion, etc.
>
> I agree, moving off of mailing list would be beneficial for certain
> discussions (esp security reports) b/c of things like attachments, links,
> etc often become a security challenge w/ email.
>
> -Matt
>
>> On Apr 5, 2024, at 6:58 PM, Clebert Suconic
>> wrote:
>>
>> I haven’t used it on the Apache Jira but I use private comments all the
>> time on my company JIRA for things that would be related to security and
>> injeritently private.
>>
>> I thought we could eventually start using a feature like that and I
>> thought
>> it would be a nice feature to keep. But if everybody think we should
>> keep
>> everything open and just use private list for private comments that’s
>> fine.
>>
>> On Fri, Apr 5, 2024 at 2:47 PM Matt Pavlovich wrote:
>>
>>> Hi Clebert-
>>>
>>> How widely used are private comments today?
>>>
>>> I ran a search and I do not see any private comments in use with the
>>> ActiveMQ project. I tried searching the ARTEMIS project, perhaps I got
>>> the
>>> JQL incorrect?
>>>
>>> project = ARTEMIS AND issueFunction in commented("group activemq-pmc”)
>>> project = ARTEMIS AND issueFunction in commented(“role PMC")
>>>
>>> An available solution would be to use a private GH repo would secure all
>>> the items — code, issues, etc.. from unprivileged users. A PMC-only repo
>>> could have issues-only or discussion-only for CVE discussions.
>>>
>>> I think private comment is a wonky concept, as it is easy to get that
>>> toggled incorrectly. I think it is better to restrict access to a
>>> secured
>>> area vs trying to feather comments.
>>>
>>> Thanks,
>>> Matt
>>>
On Apr 5, 2024, at 11:47 AM, Clebert Suconic
>>> wrote:
Is there a private comment capability on GitHub? To me that’s a
breaking
deal feature and I have never seen it.
On Fri, Apr 5, 2024 at 12:15 PM Domenico Francesco Bruscino <
bruscin...@gmail.com> wrote:
> 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 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
> >>>
> wrote:
>
>> I would prefer to k
