I would just like to add some extra positive thoughts for this. Firstly as a newcomer JIRA is confusing, even coming from a word that does use JIRA internally it's not what you see for most open source projects so it's far more familiar to use GitHub issues. (actually as a side note one negative is you may see an increase of "issues" that are actually support questions, I know this happens a lot on Jira, I don't know if you've considered standard or automatic handling)
Secondly coming from a big enterprise company I often find Apache is blocking our connection and I can almost never load Airflow's JIRA. Because we are tens of thousands of users all behind 1 IP it seems that Apache automatically blocks us often. So it will be nice to actually be able to read issues from my work computer! Damian -----Original Message----- From: Jarek Potiuk <jarek.pot...@polidea.com> Sent: Monday, March 16, 2020 10:25 To: dev@airflow.apache.org Subject: Re: [DISCUSS] Stop using Jira (since we aren't using it properly) Yep. Vote and switch :) On Mon, Mar 16, 2020 at 3:12 PM Tomasz Urbaszek <turbas...@apache.org> wrote: > Yes, vote and switch. > > > On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor <a...@apache.org> wrote: > > > 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] > > > > > > > > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/> =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
