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 <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
> >>>>>
> >>>>
> >>
> >>
>
