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