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
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.
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 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.
@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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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.
> 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
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
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
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
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
> 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
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
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
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
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
29 matches
Mail list logo
