Thanks, Imran for pointing out to the script you guys use, we will surely have a look.
On Tue, Nov 19, 2019 at 2:10 PM Imran Rashid <imranra...@gmail.com> wrote: > Hi, > > I'm mostly just a lurker here but I thought I'd point out the scripts we > use for spark: > > https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py > > It makes it easy to standardize format of commit msgs, merge to multiple > branches, and update jira. Every once in a while, somebody has to update > those scripts as an API or auth method changes somewhere, or we change the > way we want to format things. So only useful if you're willing to invest > in the scripts too. > > Hope this helps, > Imran > > On Tue, Nov 19, 2019, 7:31 AM Ash Berlin-Taylor <a...@apache.org> wrote: > > > https://github.com/go-jira/jira <https://github.com/go-jira/jira> with > > some careful scripting would go some way to doing this. There are also a > > few scripts in the dev/ folder of the repo. > > > > An example of a command I used in the last release: > > > > jira list -t list-fix -q "Key IN ($(git log --oneline --format='%s' > > 1.10.5...HEAD | grep -vi 'AIRFLOW-XXX' | grep -i 'AIRFLOW-' | perl -pe > > 's/.*(AIRFLOW-\d+).*/\U$1/i' | paste -s -d , -)) AND (fixVersion not in > > ("1.10.6") OR fixVersion is null)" > > > > (This was to find commits in my branch since 1.10.5 that weren't yet > > marked for fix in 1.10.6. It was never 100% accurate, but was close; > > > > -a > > > > > On 18 Nov 2019, at 22:14, 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/> > > > > >
