With the recent asf.yaml change, seems that we are getting to get much easier self-maintenance of bot integration from ASF. I am all for adding more bot-driven stuff :).
Probot looks absolutely great, especially that it has so many existing integrations and we can add our own if needed and contribute it back. Maybe someone would like to take on the "probot" hat and try to add some useful integrations already ? J. On Wed, Nov 20, 2019 at 8:22 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > I just used it on my fork and works nicely. Thanks, Max. > > +1 for probot > > On Tue, Nov 19, 2019 at 10:55 PM Jarek Potiuk <jarek.pot...@polidea.com> > wrote: > > > +1 for probot. How about we try it with > > https://github.com/cchantep/probot-jira for example? > > > > On Tue, Nov 19, 2019 at 8:28 PM Daniel Imberman < > daniel.imber...@gmail.com > > > > > wrote: > > > > > +1 for probot, the k8s community has a pretty slick GitHub automation > > > system as well we should look into. > > > > > > via Newton Mail [ > > > > > > https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2 > > > ] > > > On Tue, Nov 19, 2019 at 2:09 PM, Maxime Beauchemin < > > > maximebeauche...@gmail.com> wrote: > > > Quick note as I'm playing with Probot for Superset. It's possible to > > catch > > > all sorts of Github event and trigger all sorts of side effects with > it. > > > > > > On the Superset side we're looking to enable automation around Github > > > comments and labeling. It's also offers potential around enabling > people > > > (PMs, contributors) without write access to the repo to create > > > labels, assign tasks, ... > > > > > > More about it here: > > > https://probot.github.io/ > > > > > > Max > > > > > > On Mon, Nov 18, 2019 at 2:14 PM Jarek Potiuk <jarek.pot...@polidea.com > > > > > wrote: > > > > > > > Agree that Github issue are nicely integrated with the code, I don't > > > > particularly mind which issue tracking system I use as long as it has > > > good > > > > integration. > > > > > > > > The nice part about github issues that now with github actions we > could > > > > automate more and have full control over it. And a lot of this works > > > > automagically (Fixes #NN) closes the issue when merged. > > > > > > > > On the other hand It is very limiting. I see it would have been > > difficult > > > > to follow the cherry-picking workflow where we decide after the merge > > if > > > we > > > > want to cherry-pick or not. Issue can belong to only one milestone - > so > > > > then we'd have to start messing around with labels etc. I don't have > > > > particularly strong feelings about moving out of JIRA and I think the > > > > benefits are very small compared to the hassle of changing. > > > > > > > > There is a lot of "boring" work in the commiter's live - mostly > > connected > > > > with reviewing list of issues in one of the systems (sometimes many > > times > > > > over) and reacting somehow. I think it would be much more enjoyable > if > > we > > > > had - even manually driven - some automation in place for that. I > think > > > > about a small but well-rounded tool that could help with managing > state > > > of > > > > the several different system we use. > > > > > > > > I'd love a small "committer" CLI that we will be able to query the > > state > > > of > > > > the issues and use it to perform particular tasks - i.e. checking the > > > list > > > > of open issues assigned to me, issues that I have recently interacted > > > with, > > > > issues that are in the area of my interest - viewable and > discoverable > > > via > > > > the CLI, and then manageable from the same CLI. I'd love for example > to > > > see > > > > all the issues that I already merged but they are not resolved yet. > Or > > > all > > > > the issues for which build failed recently but they are likely > > transient > > > > rebuilds etc. etc. Something that could be a small (CLI) dashboard > for > > > all > > > > the committers where all the typical use-cases for the committers are > > > > automated. This way we could not only make our life easier but also > we > > > > could start promoting some good committer practices, and we could > > > introduce > > > > some more sophisticated strategies for dealing with issues (vs. > current > > > > anyone does anything strategy). For example sharing the issues > between > > > > committers, auto-assigning reviewers etc. etc. Of course this can all > > be > > > > done without such tool, but that would be far less fun if those are > > > > "written down" and "manually followed" processes rather than > automated > > > > ones. > > > > > > > > And of course myself or anyone could develop such tool myself - but > > it's > > > > quite an effort and I think it would only pay off if the effort could > > be > > > > divided by a number of people contributing, but benefits multiplied > by > > a > > > > number of people using it :). > > > > > > > > As we will have more committers (hopefully) we might have more need > for > > > > such tool. Is this a good time to start thinking about it? > > > > > > > > J. > > > > > > > > On Mon, Nov 18, 2019 at 10:12 PM Sergio Kef <sergio...@gmail.com> > > wrote: > > > > > > > > > On a slightly irrelevant note, do we ever close tickets as > > > > non-reproducable > > > > > or will-not-fix? > > > > > Last time I was going through open tickets I found dozens that > seemed > > > > > really old, really not-gonna-happen or already fixed. > > > > > What actions could we take to decrease this gap? > > > > > WDYT? > > > > > > > > > > S. > > > > > > > > > > On Mon, 18 Nov 2019 at 21:25, Tomasz Urbaszek < > > > > tomasz.urbas...@polidea.com > > > > > > > > > > > wrote: > > > > > > > > > > > I can agree that GitHub issues may get spammy but I other > projects > > > deal > > > > > > with it somehow. And as a user I like the simplicity of creating > an > > > > > issue. > > > > > > As per Jira, I think a good part of it is the ability to link > > issues > > > > > across > > > > > > different ASF project (but I don't think it's a killer feature). > > > > > > > > > > > > On Mon, Nov 18, 2019 at 9:12 PM Bolke de Bruin < > bdbr...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > I don’t like Jira particularly but I like GitHub issues even > > less. > > > > Both > > > > > > > don’t feel right. And yes GitHub issues get spammy very > quickly. > > > The > > > > > > hurdle > > > > > > > gets so low that it functions as an alternative to the mailing > > > list, > > > > > far, > > > > > > > and chat. > > > > > > > > > > > > > > > > > > > > > On 18 November 2019 at 21:05:38, Ash Berlin-Taylor ( > > a...@apache.org > > > ) > > > > > > wrote: > > > > > > > > > > > > > > Getting creds for Jira might be tricky, though Infra may have > > some > > > > way > > > > > of > > > > > > > resolving issues when PR is merged (please don't Close, only > ever > > > > > Resolve > > > > > > > as closed issues can't have FixVersion changed) > > > > > > > > > > > > > > This brings me on to another question: what do were actual use > > Jira > > > > for > > > > > > > that couldn't (or shouldn't) be done with GitHub Issues? > > > > > > > > > > > > > > The main thing I can think of right now is the Fix version when > > > > > resolving > > > > > > > to say when we should backport a PR, but this could be achieved > > > with > > > > > > > Milestones in GitHub. > > > > > > > > > > > > > > (A fringe benefit is that most people won't have an ASF Jira > > > account > > > > so > > > > > > > opening issues to ask questions is harder. "Benefit" as it > avoids > > > > issue > > > > > > > spam for question.) > > > > > > > > > > > > > > Is there anything else? > > > > > > > > > > > > > > -A > > > > > > > > > > > > > > On 18 November 2019 18:27:16 GMT, Tomasz Urbaszek < > > > > > > > tomasz.urbas...@polidea.com> wrote: > > > > > > > >Is there any possibility to use GitHub actions for that? > > > > > > > >For example, the one that allows to "Automatically transition > an > > > > issue > > > > > > > >to > > > > > > > >done when a pull request whose name contains the issue key is > > > > merged"? > > > > > > > >Here is Atlassian repo: https://github.com/atlassian/gajira > > > > > > > > > > > > > > > >Bests, > > > > > > > >Tomek > > > > > > > > > > > > > > > > > > > > > > > >On Mon, Nov 18, 2019 at 7:22 PM Bolke de Bruin < > > bdbr...@gmail.com > > > > > > > > > > > >wrote: > > > > > > > > > > > > > > > >> I wrote that script. It’s cli only unfortunately. > > > > > > > >> > > > > > > > >> > > > > > > > >> On 18 November 2019 at 18:22:04, Dan Davydov > > > > > > > >(ddavy...@twitter.com.invalid > > > > > > > >> ) > > > > > > > >> wrote: > > > > > > > >> > > > > > > > >> Wait this doesn't happen automatically!? I thought > > way-back-when > > > > > > > >someone > > > > > > > >> wrote a script to automatically close the JIRA tickets > (maybe > > > that > > > > > > > >script > > > > > > > >> is not run when changes are merged via the UI). My > apologies, > > > will > > > > > > > >close > > > > > > > >> JIRAs in the future, I don't think I've closed any JIRA > > tickets > > > > > > > >manually. > > > > > > > >> > > > > > > > >> On Sat, Nov 16, 2019 at 5:14 AM Jarek Potiuk > > > > > > > ><jarek.pot...@polidea.com> > > > > > > > >> wrote: > > > > > > > >> > > > > > > > >> > And yes. I was one of the culprits - I saw :(. Sorry about > > > that > > > > > > > >Kaxil. > > > > > > > >> > Just hope we can streamline this :). > > > > > > > >> > > > > > > > > >> > On Sat, Nov 16, 2019 at 10:12 AM Jarek Potiuk > > > > > > > ><jarek.pot...@polidea.com> > > > > > > > >> > wrote: > > > > > > > >> > > > > > > > > >> > > Heartily agree with it ! > > > > > > > >> > > > > > > > > > >> > > I try always to close the PRs but sometimes I got > > distracted > > > > and > > > > > > > >forget > > > > > > > >> > to > > > > > > > >> > > resolve an issue - it happend several times that I > > recalled > > > it > > > > > > > >few > > > > > > > >> hours > > > > > > > >> > > later that I have forgotten to resolve it. I hope it > > happens > > > > > > > >rarely - > > > > > > > >> I'd > > > > > > > >> > > love to know if I was one of the culprits here :). And > > > > whenever > > > > > I > > > > > > > >> noticed > > > > > > > >> > > some of the PRs are not closed but PR is merged by > someone > > > > else > > > > > - > > > > > > > >I > > > > > > > >> > > sometimes close them. But it's not ideal of course. > > > > > > > >> > > > > > > > > > >> > > However simple it is - I think we are just humans and we > > > will > > > > > > > >forget > > > > > > > >> from > > > > > > > >> > > time to time. I was wondering if we can (yes, you > guessed > > > it) > > > > > > > >automate > > > > > > > >> it > > > > > > > >> > > :). Either with JIRA/Github integration or some > automated > > > tool > > > > > to > > > > > > > >do it > > > > > > > >> > > regularly and resolving all already merged tickets. And > > the > > > > more > > > > > > > >> > > committers we are going to have, the more it makes sense > > to > > > > > > > >automate > > > > > > > >> some > > > > > > > >> > > of the work. The less you have to remember about your > > > "chores" > > > > > > > >the more > > > > > > > >> > you > > > > > > > >> > > can focus on the "real" stuff. > > > > > > > >> > > > > > > > > > >> > > I think there are a few unwritten rules that we have - > > like > > > > what > > > > > > > >> version > > > > > > > >> > > to set when we cherry-pick change to 1.10* . My > > > understanding > > > > is > > > > > > > >that > > > > > > > >> we > > > > > > > >> > > should set fixed version to the first unreleased yet > 1.10. > > > > > > > >version. > > > > > > > >> This > > > > > > > >> > > problem will soon be gone, so maybe it's not worth > solving > > > it. > > > > > > > >There > > > > > > > >> are > > > > > > > >> > > also some edge cases like bad fixes which got reverted > and > > > > > > > >reapplied > > > > > > > >> but > > > > > > > >> > I > > > > > > > >> > > think other than that the automation of it can be rather > > > > simple. > > > > > > > >> > > > > > > > > > >> > > And I think there are some scripts in "dev" that already > > do > > > > some > > > > > > > >of > > > > > > > >> that > > > > > > > >> > - > > > > > > > >> > > synchronising merges with JIRAs (but I don't think it's > > > common > > > > > > > >> knowledge > > > > > > > >> > > and it's not regularly run). Maybe we can improve it > > somehow > > > > and > > > > > > > >have > > > > > > > >> it > > > > > > > >> > > fully automated so that we do not even havet to think > > about > > > > it ? > > > > > > > >> > > > > > > > > > >> > > WDYT? Any ideas? > > > > > > > >> > > > > > > > > > >> > > J. > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > On Sat, Nov 16, 2019 at 1:19 AM Kaxil Naik < > > > > kaxiln...@gmail.com > > > > > > > > > > > > > >> wrote: > > > > > > > >> > > > > > > > > > >> > >> We have some at > > > > > > > >> > >> > > > > > > > >> > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/Committers%27+Guide > > > > > > > >> > >> > > > > > > > >> > >> The person who merges the PR to master is the one who > > would > > > > be > > > > > > > >> > responsible > > > > > > > >> > >> for resolving the JIRA issue as they can add the > *target > > > > > > > >version* > > > > > > > >> based > > > > > > > >> > on > > > > > > > >> > >> what they think after reviewing the PR. > > > > > > > >> > >> > > > > > > > >> > >> On Sat, Nov 16, 2019 at 12:12 AM Aizhamal Nurmamat > kyzy < > > > > > > > >> > >> aizha...@apache.org> > > > > > > > >> > >> wrote: > > > > > > > >> > >> > > > > > > > >> > >> > I think it will be good to document the process. For > > > > example, > > > > > > > >who is > > > > > > > >> > >> > responsible for closing Jira issues: folks who closed > > > PR's > > > > or > > > > > > > >the > > > > > > > >> ones > > > > > > > >> > >> who > > > > > > > >> > >> > opened? > > > > > > > >> > >> > > > > > > > > >> > >> > If the documentation already exists, let's bring it > > back > > > to > > > > > > > >> attention. > > > > > > > >> > >> > > > > > > > > >> > >> > On Fri, Nov 15, 2019 at 4:06 PM Kaxil Naik > > > > > > > ><kaxiln...@gmail.com> > > > > > > > >> > wrote: > > > > > > > >> > >> > > > > > > > > >> > >> > > Hi Committers, > > > > > > > >> > >> > > > > > > > > > >> > >> > > Please make sure to close the Jira issues if the > > > related > > > > > PRs > > > > > > > >are > > > > > > > >> > >> merged. > > > > > > > >> > >> > > > > > > > > > >> > >> > > I am going through the Jira Reports (Image: > > > > > > > >> > https://imgur.com/n50Ticx > > > > > > > >> > >> ) > > > > > > > >> > >> > and > > > > > > > >> > >> > > was concerned with the gap between issues created & > > > > > resolved > > > > > > > >in > > > > > > > >> > recent > > > > > > > >> > >> > > months. > > > > > > > >> > >> > > > > > > > > > >> > >> > > However, I noticed while going through the jira > > issues > > > > that > > > > > > > >most > > > > > > > >> of > > > > > > > >> > >> the > > > > > > > >> > >> > PRs > > > > > > > >> > >> > > related to the JIRAs have been resolved but the > JIRA > > is > > > > not > > > > > > > >> > resolved. > > > > > > > >> > >> > > > > > > > > > >> > >> > > Let's try to resolve all the issues when we merge > the > > > PR > > > > :) > > > > > > > >> > >> > > > > > > > > > >> > >> > > This will help the release manager too. > > > > > > > >> > >> > > > > > > > > > >> > >> > > Regards, > > > > > > > >> > >> > > Kaxil > > > > > > > >> > >> > > > > > > > > > >> > >> > > > > > > > > >> > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > -- > > > > > > > >> > > > > > > > > > >> > > 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/> > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > > > > > > > > > > > > >Tomasz Urbaszek > > > > > > > >Polidea <https://www.polidea.com/> | Junior Software Engineer > > > > > > > > > > > > > > > >M: +48 505 628 493 <+48505628493> > > > > > > > >E: tomasz.urbas...@polidea.com <tomasz.urbasz...@polidea.com> > > > > > > > > > > > > > > > >Unique Tech > > > > > > > >Check out our projects! <https://www.polidea.com/our-work> > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Tomasz Urbaszek > > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer > > > > > > > > > > > > M: +48 505 628 493 <+48505628493> > > > > > > E: tomasz.urbas...@polidea.com <tomasz.urbasz...@polidea.com> > > > > > > > > > > > > Unique Tech > > > > > > Check out our projects! <https://www.polidea.com/our-work> > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > 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/> > > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
