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 <mattr...@gmail.com> 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 <mattr...@gmail.com> 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 <robbie.gemm...@gmail.com>
> >> 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 <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
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
>
