Yeah, Superset is using GIthub Issues instead of Jira.
This is probably the third or fourth time the Github/Jira subject has been
brought up, something just finally pushed me over the edge of "why are we
bothering with this" today.
It seems like we have fairly broad agreement this time. AIP worth, or just a
VOTE and switch over?
-a
On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <turbas...@apache.org> wrote:
> +1 for Github issues. Github allows creating issue template (feature, bug,
> custom) so this should help. And I have a feeling that GH issues are indexed
> better than JIRA tickets. JIRA gives the possibility to interlink between ASF
> projects but I don't think is something important for us. I've also spotted
> that Apache Superset is proposing SIP (Superset Improvement Proposals) on
> Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM Kaxil Naik wrote: > > +1 >
> > One other problem it would help us solve is *closing issues where the PR is
> > merged*. This is one of the pain-points for us, some of the JIRA issues are
> > open even though the PR is merged. > > With Github issues, if there is a PR
> solving an existing issue just adding > "fixes #20" would close that issue
> when PR is merged. > > Regards, > Kaxil > > > > On Mon, Mar 16, 2020 at 12:04
> PM Ash Berlin-Taylor wrote: > > > > Maybe we could have some clear guidelines
> on when the issues should be > > created - only when there is a problem so
meone wants to report and we have > > no code for it yet. > > > > Yes, exactly.
If you want to submit a fix directly: great, open a PR; if > > you want to
report it but arent able/willing to submit a fix straight away: > > create an
issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek Potiuk > > wrote: > > > I
am all for it. We can easily rely just on PR# to uniquely identify > > commit
rather than Github issue id - and remove the requirement to have an > > issue
altogether? The issue can be added optionally but it should not be a > >
requirement. I think PRs and Issues are pretty equivalent when you follow > >
the "work" + "create" +" submit" sequence - without the unnecessary hassle. > >
You can assign milestones/projects/label the same way on both. We actually > >
found that even when we use them in some other projects - they become > >
unnecessary. I think eventually there should be a way to convert an issue > >
into PR :). Even if we want to use Github Projects eventually, we ca
n add > > PRs to projects similarly as issues. Maybe we could have some clear >
> guidelines on when the issues should be created - only when there is a > >
problem someone wants to report and we have no code for it yet. J. On Mon, > >
Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > I'm totally in favor > >
of not using Jira, as they are serving hardly > > any > purpose other than just
a useless step before creating a PR. > > However, I > don't think to make a
GitHub issue mandatory is also a good > > step, as > eventually, it'll meet the
same fate of being opened just before > > opening a > PR. > > > So IMO we can
use Github issues for simple use, which > > is to report some > bugs/questions
by users, who are not necessarily > > planning to create a PR > soon. > Yes,
that was what I meant but I wasn't > > clear; I was just using "Github >
Issues" as a collective product name, and > > not saying we need an issue for >
every PR. > > -ash > > On Mar 16 2020, at > > 11:42 am, Sumi
t Maheshwari > wrote: > > I'm totally in favor of not using > > Jira, as they
are serving hardly any > purpose other than just a useless > > step before
creating a PR. However, I > don't think to make a GitHub issue > > mandatory is
also a good step, as > eventually, it'll meet the same fate of > > being opened
just before opening a > PR. So IMO we can use Github issues > > for simple use,
which is to report some > > > bugs/questions by users, who are not necessarily
planning to create a > > PR > soon. Also, if we go this route, then we can do
the one time Jira > > cleanup > and port only valid issues in Github. On Mon,
Mar 16, 2020 at > > 5:07 PM Ash > Berlin-Taylor wrote: > Yeah, Github issues
are far from > > perfect, it's > mainly just I feel we have > a lot of
"busy-work" in our > > process that is no > longer really serving much >
benefit to us as a > > community. > > -a > On Mar > 16 2020, at 11:35 am, Bolke
de Bruin wrote: > > > > Honestly, I think both > suck. So I can go ei
ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash > Berlin-Taylor
(a...@firemirror.com > (mailto: > > a > s...@firemirror.com)) wrote: > > > The
subject pretty much says it all. > > > > > > We aren't using Jira very well in
most cases, and the requirement > > for > a > Jira ticket for a code change
leads to people just creating new > > Jira > > tickets, rather than searching
to see if there already exists a > > ticket for > > that feature. > > > For
example: > ht > > tps://issues.apache.org/jira/browse/AIRFLOW-6987 and > > > >
https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > > > >
pick on anyone involved here, I just happened to notice this) > > > > > >
Additionally most of the committers follow a similar path of "work on > > > >
feature, open Jira ticket just before creating PR". > > > I am proposing we > >
> migrate over to Github issues and drop the > requirement to have a jira > > >
ticket for PRs. > > > The one downside is we might get people opening
> > > issues for as an > "help, how do I do this" -- I think we can address
> > > that > > > by having an issue > template saying something like "DO NOT
> > > OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join slack".
> > > > > > The only > > other thing Jira currently gives us is > the ability
> > > mark tasks > for > > "backporting" -- I think we can replace that > with
> > > Github Milestones. > > > Kaxil or I will happily update the scripts we
> > > use > to build/check the > > status > of releases. > > > Thoughts? > > >
> > > The only > outstandi > > ng question is then what do we do about
> > > migrating > the issue (do > we > > copy issues across to Github?).
> > > Perhaps it might be a good > opportunity > > > for a clean slate. > > >
> > > -ash > > > > > > > > > > > > -- Jarek Potiuk > > Polidea | Principal
> > > Software Engineer M: +48 660 796 129 <+48660796129> > > [image: Polidea]
> > > > > > >
