Calcite just requested a separate mailing list for users to request a
JIRA account.
I think I'd try going a similar route. While I prefer the openness of
github issues, they are really limited, and while some things can be
replicated with labels (like fix versions / components), things like
release notes can't.
We'd also lose a central place for collecting issues, since we'd have to
(?) scope issues per repo.
I wouldn't want to import everything into GH issues (it's just a flawed
approach in the long-term imo), but on the other hand I don't know if
the auto linker even works if it has to link to either jira or a GH issue.
Given that we need to change workflows in any case, I think I'd prefer
sticking to JIRA.
For reported bugs I'd wager that in most cases we can file the tickets
ourselves and communicate with users on slack/MLs to gather all the
information. I'd argue that if we'd had been more pro-active with filing
tickets for user issues (instead of relying on them to do it) we
would've addressed several issues way sooner.
Additionally, since either option would be a sort of experiment, then
JIRA is a safer option. We have to change less and there aren't any
long-term ramifications (like having to re-import GH tickets into JIRA).
On 28/10/2022 16:49, Piotr Nowojski wrote:
Hi,
I'm afraid of the migration cost to only github issues and lack of many
features that we are currently using. That would be very disruptive and
annoying. For me github issues are far worse compared to using the Jira.
I would strongly prefer Option 1. over the others. Option 4 I would like
the least. I would be fine with Option 3, and Option 2 but assuming that
Jira would stay the source of truth.
For option 2, maybe we could have a bot that would backport/copy user
created issues in github to Jira (and link them together)? Discussions
could still happen in the github, but we could track all of the issues as
we are doing right now. Bot could also sync it the other way around (like
marking tickets closed, affected/fixed versions etc).
Best,
Piotrek
czw., 27 paź 2022 o 07:48 Martijn Visser <martijnvis...@apache.org>
napisał(a):
Hi,
We have to keep in mind that if a users asks for a new Jira account, that
person will need to provide its email address which is the Flink PMC
processing personal identifiable information. There needs to be a careful
process for that and to be honest, I don't think the ASF should do this
from a privacy perspective.
As an example, the Calcite community decided to create a dedicated, private
list where users can ask for an account to avoid making the email address
public.
Best regards,
Martijn
Op wo 26 okt. 2022 om 22:31 schreef Danny Cranmer <dannycran...@apache.org
Hello,
I agree with Gyula. My preference is also option 1, and as a fallback
option 3. Handling new user account requests will be manageable,
especially
via slack. We could setup a dedicated channel for people to ask for
Jira/wiki access.
Thanks,
Danny
On Wed, 26 Oct 2022, 12:16 Gyula Fóra, <gyf...@apache.org> wrote:
Hi!
I would also personally prefer staying with JIRA given the feature set
and
the past positive experience with it.
I think the structured nature of JIRA with flexible components, issue
types, epics, release handling etc have been a great benefit to the
project, it would be a shame to give some of these up.
If for some reason Option 1 is not possible, I would still prefer
Option
3
(requiring new contributors to ask for JIRA access) compared to the
alternatives.
Cheers,
Gyula
On Tue, Oct 25, 2022 at 3:48 PM Robert Metzger <rmetz...@apache.org>
wrote:
Thank you for starting this discussion Xintong!
I would also prefer option 1.
The ASF Jira is probably one of the largest, public Jira instances on
the
internet. Most other Jiras are internal within companies, so
Atlassian
is
probably not putting a lot of effort into automatically detecting and
preventing spam and malicious account creation.
If we want to convince Infra to keep the current sign up process, we
probably need to help them find a solution for the problem.
Maybe we can configure the ASF Jira to rely on GitHub as an identity
provider? I've just proposed that in the discussion on
us...@infra.apache.org, let's see ;)
Best,
Robert
On Tue, Oct 25, 2022 at 2:08 PM Konstantin Knauf <kna...@apache.org>
wrote:
Hi everyone,
while I see some benefits in moving to Github Issues completely, we
need
to
be aware that Github Issues lacks many features that Jira has. From
the
top
of my head:
* there are no issue types
* no priorities
* issues can only be assigned to one milestone
So, you need to work a lot with labels and conventions and
basically
need
bots or actions to manage those. Agreeing on those processes,
setting
them
up and getting used to them will be a lot of work for the
community.
So, I am also in favor of 1) for now, because I don't really see a
good
alternative option.
Cheers,
Konstantin
Am Mo., 24. Okt. 2022 um 22:27 Uhr schrieb Matthias Pohl
<matthias.p...@aiven.io.invalid>:
I agree that leaving everything as is would be the best option. I
also
tend
to lean towards option 4 as a fallback for the reasons already
mentioned.
I'm still not a big fan of the Github issues. But that's probably
only
because I'm used to the look-and-feel and the workflows of Jira.
I
see
certain benefits of moving to Github, though. We're still having
the
idea
of migrating from AzureCI to GitHub Actions. Moving the issues to
GitHub
as
well might improve the user experience even more. Reducing the
number
of
services a new contributor should be aware of to reach the
community
is a
good way to reduce the confusion for newcomers, I could imagine.
Additionally, I also like the fact that I wouldn't have to bother
about
the
Apache Jira markdown anymore. 8)
I agree with Martijn's concern about not being able to track all
Flink-related issues in a single system. I'm just wondering
whether
something is holding us back from collecting all Flink-related
issues
in
the Flink's Github repository and disabling the issue feature in
any
other
Flink-related repository?
About migrating the Jira issues: I would be hopeful that
migrating
is
doable in the end. There is a blog post from the spring data guys
about
their journey on migrating from Jira to GitHub issues [1].
Unfortunately,
they didn't provide any scripts.
For the case that infra moves forward with disabling the signup
without
us
having come up with a decision and its actual execution (i.e.
migrating
the
Jira issues to GH), I would prefer having users send a request to
the
mailing list. I would rather have a temporary phase where
there's a
bit
of
overhead of registering the users in the Apache Jira than having
two
locations for bug tracking. I suspect that there are no
statistics
on
how
many new users register with Jira in a given timeframe to
contribute
to
Flink?
Matthias
[1]
https://spring.io/blog/2021/01/07/spring-data-s-migration-from-jira-to-github-issues
[2]
https://lists.apache.org/thread/pjb5jzvw41xjtzgf4w0gggpqrt2fq6ov
On Mon, Oct 24, 2022 at 10:28 AM Xintong Song <
tonysong...@gmail.com
wrote:
I agree with you that option 1) would be the best for us. Let's
keep
hoping
for the best.
Option 4), as you said, comes with prices. At the moment, I
don't
have
thorough answers to your questions.
Just one quick response, I think there's a good chance that we
can
import
current Jira tickets into GH. Jira supports exporting issues
with
fields
that you specified as CSV/XML/... files. With a brief google
search,
I
found some tools that help bulk creating issues in GH. E.g.,
github-csv-tools [1] is described to support importing issues
with
title,
body, labels, status and milestones from a CSV file. That's
probably
good
enough for us to search/filter the issues in GH, and a link to
the
Jira
ticket can be posted in the GH issue for complete conversation
history
and
other details.
Best,
Xintong
[1] https://github.com/gavinr/github-csv-tools
On Mon, Oct 24, 2022 at 3:58 PM Martijn Visser <
martijnvis...@apache.org
wrote:
Hi Xintong,
I'm also not in favour of option 2, I think that two systems
will
result
in an administrative burden and less-efficient workflow. I'm
also
not
in
favour of option 3, I think that this will result in first
time
users/contributors in not-filling their first bug report,
user
question
or
feature request.
I'm still hoping for option 1 while the discussion is not
finished
with
Infra.
If we assume that option 1 won't be possible, then I think
option 4
will
be the best-option-left. I'm not necessarily in favour,
because
of
a
number
of problems it will introduce:
1. I don't think importing current Jira tickets into Github
Issues
is a
realistic option. So we would have two administrations.
Before
you
create a
new ticket, you should check if it exists both as a Jira
ticket
and
as
a
Github Issue.
2. How would we deal with completing a PR? There must be one
administration leading for the changelog generation (to avoid
that
you're
missing an item), which could then only be Github Issues. So
would
we
require all PRs that are merged to exist as a Github Issue?
3. There's no longer one central administration, which is
especially
valuable to track all issues across projects like the
different
connectors,
Flink ML, Table Store etc.
4. Our current CI labeling works on the Jira issues, not on
the
Github
Issues labels.
Best regards,
Martijn
On Mon, Oct 24, 2022 at 7:29 AM Xintong Song <
tonysong...@gmail.com>
wrote:
Hi devs and users,
As many of you may have already noticed, Infra announced
that
they
will
soon disable public Jira account signups [1]. That means, in
order
for
someone who is not yet a Jira user to open or comment on an
issue,
he/she
has to first reach out to a PMC member to create an account
for
him/her.
This raises the bar for new contributors and users to
participate
in
community interactions, making it necessary for us to
consider
whether
(and
how) we should change our issue tracking workflows.
I can see a few possible options.
1. Reaching out to Infra and trying to change their mind on
this
decision. I’ve already been trying this [2], and so far the
feedback
seems
unoptimistic.
2. Using both Jira (for development issues) & Github Issues
(for
customer-facing issues), as Infra suggested.
3. Stay with using Jira only, so that new Jira users need to
ask
on
the
mailing lists / Slack for creating accounts.
4. Migrating to Github Issues completely.
Personally, I’m leaning toward option 4).
TBH, I don’t see any good reason for option 2). I’d expect
using
two
different issue tracking tools at the same time would be
complex
and
chaotic. Option 3) is probably more friendly to existing
developers
and
users, while being less friendly to newcomers. Option 4) on
the
contrary,
is more friendly to newcomers, at some migration cost which
might
be
non-trivial but once for all.
Github issues have been widely used by many open source
projects,
including Kubernetes, Flink CDC, and Apache projects Iceberg
and
Airflow.
With a set of well-designed labels, we should be able to
achieve
most
of
the Jira functions / features that we currently rely on.
Moreover,
it
better integrates the issue tracking and code contributing
systems,
and
would be easier to access (I believe there’s more GH users
than
Jira /
mailing lists).
All in all, I’d suggest to keep monitoring Infra’s feedback
on
option
1),
while taking steps (investigation, workflow & label design)
preparing
for
option 4).
Looking forward to hearing what you think about this.
Best,
Xintong
[1]
https://lists.apache.org/thread/jx9d7sp690ro660pjpttwtg209w3m39w
[2]
https://lists.apache.org/thread/fjjtk30dxf6fyoo4q3rmkhh028or40fw
--
https://twitter.com/snntrable
https://github.com/knaufk
--
Martijn
https://twitter.com/MartijnVisser82
https://github.com/MartijnVisser
