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 <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
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
>
>
--
perl -e 'print
unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );'
http://bsnyder.org/ <http://bruceblog.org/>
