And for the clean state -> I am rather for a "brute" approach. I.e. review them and only move those that people reviewing them find necessary to keep. Mark the others as stale, add comment "we are closing them in a week - please create a github issue if you want to keep it" and close the remaining ones a week later. They will still be there (but closed) and we can always ressurrect them as needed.
I think we can do it at any time (maybe after or at 1.10.10 release). J. On Mon, Mar 16, 2020 at 1:02 PM Jarek Potiuk <jarek.pot...@polidea.com> 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 can 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 <a...@apache.org> 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, Sumit Maheshwari <sumeet.ma...@gmail.com> >> 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 either 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: >> https://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 >> outstanding 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 <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/> > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
