ial PR".
>
> (I think that https://github.com/apache/arrow/pull/9576 that
> is referred from the PR is a trivial PR. I don't think that
> we need an associated JIRA issue for it.)
>
>
> I haven't read all discussions yet but I hope that I can get
> an insight
he/arrow/pull/9576 that
is referred from the PR is a trivial PR. I don't think that
we need an associated JIRA issue for it.)
I haven't read all discussions yet but I hope that I can get
an insight from them. Thanks all.
Thanks,
--
kou
In
"Re: Requirements on JIRA usage i
To be clear, I have no objection to JIRA and I like the point that a little
friction on contribution may encourage more structured contribution and
planning.
As Neil mentioned, my original goal with this thread was to understand any
non-technical reason that prevented automating the creation of JI
With regards to the actual work of merging patches. I have merged
3,234 patches in this project [1], so I think this qualifies me to
have an opinion about this. I don't think that the merge tool is
problematic -- I use a little bash helper function [2] which cuts down
my work merging a patch down t
A few thoughts:
* Given the cost of switching issue trackers (even if we were to identify
one we thought was better), I think it's extremely unlikely that we would
abandon JIRA. So rather than dumping on JIRA (an easy target, of course),
we should focus on how we can make the workflows we have smo
It also seems like we're describing two different issues. The first,
a barrier to entry for new development. The second, overhead imposed
on an active developer. I'm personally not so worried about the
overhead imposed, perhaps because I can't write code that fast
anyways, so I'll stay out of th
Hi Antoine,
Can you expand a bit on this? In particular, which aspects of using
> JIRA feel bureaucratic? Is it the requirement to create a new issue
> for each PR? Or is it other concerns (such as the UI for entering or
> searching issues)?
>
First of all, thank you for taking my concerns and
Hi,
I'd just like to mention that we already have a fair amount of tooling
around jira,
so switching to another issue tracker would require some additional
development effort:
- automatized pull-request issue linkage
- merge script
- various release scripts
- cherry-pick tooling for patch releases
> FWIW, the amount of bureaucracy that goes into JIRA is a major contributing
> factor for the reduction of my time commitment to this project by 80%+.
This seems a bit overly dramatic to me =) Let's dig more into what are
the actual problems. I admit that adding people to the Contributor
role in
Have we ever considered GitHub issues to Jira sync?
This way users could choose to use GitHub but Jira would still be the
single source of truth.
Rok
On Tue, Mar 2, 2021 at 1:15 PM Adam Lippai wrote:
> Antoine,
>
> you are right I'm directly challenging the statement that any issue
> tracker, f
Antoine,
you are right I'm directly challenging the statement that any issue
tracker, forum or chat is as good as GitHub.
I'm not speaking about tools and efficiency. In those terms you are
absolutely right and most of the solutions are clearly superior to GitHub.
I was talking about reach, commu
On Tue, 2 Mar 2021 11:10:23 +0100
Adam Lippai wrote:
>
> All the (multiple) mailing lists, stack overflow and JIRA are definitely
> barriers for new contributors.
I'm not sure what Stack Overflow has to do with this? Interaction with
Stack Overflow isn't required to contribute to Arrow.
(also,
Hi Fernando,
On Tue, 2 Mar 2021 10:10:45 +
Fernando Herrera wrote:
>
> Adding my two cents to this thread. I would suggest that the Jira format
> imposes a high wall for newcomers. Since I have been trying to help with
> the project, I have to get familiar with Jira to be able to help with
Hi,
Adding my two cents to this thread. I would suggest that the Jira format
imposes a high wall for newcomers. Since I have been trying to help with
the project, I have to get familiar with Jira to be able to help with
little changes.
I cannot imagine how much more work others that are contributi
I've seen multiple Apache projects using GitHub for issue tracking, but are
not really positive examples.
Often they don't use the milestones and labels available, I'd be sad if
we'd end up with that style.
GitHub on it's own is usually good enough if used correctly, when it's
helped with bots.
Th
Hi Jorge,
On Tue, 2 Mar 2021 08:55:03 +0100
Jorge Cardoso Leitão wrote:
> Hi,
>
> FWIW, the amount of bureaucracy that goes into JIRA is a major contributing
> factor for the reduction of my time commitment to this project by 80%+.
Can you expand a bit on this? In particular, which aspects o
AM
To: dev@arrow.apache.org
Subject: Re: Requirements on JIRA usage in Apache Arrow
Hi,
Can we discuss whether we change the platform of a single point
of truth for developer activity to GitHub from JIRA? Can we
follow "The Apache Way" with GitHub? What pros/cons do we
have by changing
; Thanks,
> --
> kou
>
> In
> "Re: Requirements on JIRA usage in Apache Arrow" on Sat, 27 Feb 2021
> 15:48:04 -0500,
> Andrew Lamb wrote:
>
> > Here is a proposed improvement to merge_pr.py that will offer to create a
> > JIRA issue from a github PR if
y thoughts?
Thanks,
--
kou
In
"Re: Requirements on JIRA usage in Apache Arrow" on Sat, 27 Feb 2021 15:48:04
-0500,
Andrew Lamb wrote:
> Here is a proposed improvement to merge_pr.py that will offer to create a
> JIRA issue from a github PR if one does not exist:
>
>
Here is a proposed improvement to merge_pr.py that will offer to create a
JIRA issue from a github PR if one does not exist:
https://github.com/apache/arrow/pull/9598
On Wed, Feb 17, 2021 at 4:50 PM Wes McKinney wrote:
> Read more (this is one ASF member's interpretation of the Openness
> tenet
Read more (this is one ASF member's interpretation of the Openness
tenet of the Apache Way) about this:
http://theapacheway.com/open/
On Wed, Feb 17, 2021 at 3:46 PM Wes McKinney wrote:
>
> For trivial PRs that do not merit mention in the changelog you could
> preface the issue title with someth
I like the idea of encouraging regular contributors to use JIRA more
consistently
On Wed, Feb 17, 2021 at 4:47 PM Wes McKinney wrote:
> For trivial PRs that do not merit mention in the changelog you could
> preface the issue title with something like "ARROW-XXX" and we can
> modify the merge too
For trivial PRs that do not merit mention in the changelog you could
preface the issue title with something like "ARROW-XXX" and we can
modify the merge tool to bypass the consistency check for these. I
think some other Apache projects do this. I can understand how it
might seem like a nuisance to
Thanks for the background Wes. This is exactly what I was looking for.
I think using JIRA for the single source of truth / project management has
lots of value and I don't want to propose changing that. I am trying to
lower the barrier to contributing to Arrow even more.
While I agree creating JI
hi Andrew,
There isn't a hard requirement. It's a culture thing where the purpose
of Jira issues is to create a changelog and for developers to
communicate publicly what work they are proposing to perform in the
project. We decided by consensus (essentially) that having a single
point of truth for
25 matches
Mail list logo
