I am all for automation too. For now, I think the priority to build that is low. Once we have all the items in the Roadmap close to being done, we can surely get this kind of CLI built.
Regards, Kaxil On Mon, Nov 18, 2019 at 10: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/> >
