You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lens.apache.org by Rajat Khandelwal <pr...@apache.org> on 2015/05/13 11:13:27 UTC
Patch review tool: Integrating reviewboard and jira
So Yash started this by picking Kafka's tool for similar things and
modifying for our use case, and then I picked it up hoping to generalise
what Kafka did. But, quoting Tolkien, "the tale grew in the telling". I
pulled the script out and created a separate repo:
https://github.com/prongs/rbt-jira. now I'm aiming at the following:
- rbt-jira post-review -j jira-id: create a reviewboard entry for
jira-id, or update an existing one, if any.
- rbt-jira submit-patch -j jira-id: for jira-id, if a reviewboard entry
is there, take latest patch from there, otherwise take patch by doing "git
diff". After getting the patch, upload it to jira and mark the jira as
patch available
Both these commands are implemented. As an added bonus, you don't even have
to provide jira id if your branch name is same as jira id :).
Two more stretch goals I had were the following commands:
- rbt-jira commit -j jira1 jira2 jira3: Only for committers. Should
check each jira in the provided list, see if they are patch available, take
latest patch from jira, commit it and push to trunk. Right now giving up on
this because I'm hitting https://issues.apache.org/jira/browse/INFRA-6008.
But will pick up again in free time and follow up with infra team.
- rbt-jira clean: delete merged branches from your fork, fork's local
clone, close submitted review requests, clean up any local storage used by
other commands. Not essential right now.
I can release the tool with version numbers, stand alone installation,
single command access etc. but right now I want users (and myself) to use
it while it's developing, so that issues might be caught early on.
The usage of the tool is documented in the repo. Please use the tool and
keep providing feedback. :). Special thanks to Yash for bringing the idea.
Thanks and Regards
Re: Patch review tool: Integrating reviewboard and jira
Posted by Yash Sharma <ya...@gmail.com>.
Great work Rajat. All the credit goes to you for shaping the tool in a
wonderful form :)
On Wed, May 13, 2015 at 2:51 PM, amareshwarisr . <am...@gmail.com>
wrote:
> Nice Rajat! Thats awesome!
>
> On Wed, May 13, 2015 at 2:43 PM, Rajat Khandelwal <pr...@apache.org>
> wrote:
>
> > So Yash started this by picking Kafka's tool for similar things and
> > modifying for our use case, and then I picked it up hoping to generalise
> > what Kafka did. But, quoting Tolkien, "the tale grew in the telling". I
> > pulled the script out and created a separate repo:
> > https://github.com/prongs/rbt-jira. now I'm aiming at the following:
> >
> >
> > - rbt-jira post-review -j jira-id: create a reviewboard entry for
> > jira-id, or update an existing one, if any.
> > - rbt-jira submit-patch -j jira-id: for jira-id, if a reviewboard
> entry
> > is there, take latest patch from there, otherwise take patch by doing
> > "git
> > diff". After getting the patch, upload it to jira and mark the jira as
> > patch available
> >
> > Both these commands are implemented. As an added bonus, you don't even
> have
> > to provide jira id if your branch name is same as jira id :).
> >
> > Two more stretch goals I had were the following commands:
> >
> >
> > - rbt-jira commit -j jira1 jira2 jira3: Only for committers. Should
> > check each jira in the provided list, see if they are patch available,
> > take
> > latest patch from jira, commit it and push to trunk. Right now giving
> > up on
> > this because I'm hitting
> > https://issues.apache.org/jira/browse/INFRA-6008.
> > But will pick up again in free time and follow up with infra team.
> > - rbt-jira clean: delete merged branches from your fork, fork's local
> > clone, close submitted review requests, clean up any local storage
> used
> > by
> > other commands. Not essential right now.
> >
> > I can release the tool with version numbers, stand alone installation,
> > single command access etc. but right now I want users (and myself) to use
> > it while it's developing, so that issues might be caught early on.
> >
> >
> > The usage of the tool is documented in the repo. Please use the tool and
> > keep providing feedback. :). Special thanks to Yash for bringing the
> idea.
> >
> >
> > Thanks and Regards
> >
>
Re: Patch review tool: Integrating reviewboard and jira
Posted by "amareshwarisr ." <am...@gmail.com>.
Nice Rajat! Thats awesome!
On Wed, May 13, 2015 at 2:43 PM, Rajat Khandelwal <pr...@apache.org> wrote:
> So Yash started this by picking Kafka's tool for similar things and
> modifying for our use case, and then I picked it up hoping to generalise
> what Kafka did. But, quoting Tolkien, "the tale grew in the telling". I
> pulled the script out and created a separate repo:
> https://github.com/prongs/rbt-jira. now I'm aiming at the following:
>
>
> - rbt-jira post-review -j jira-id: create a reviewboard entry for
> jira-id, or update an existing one, if any.
> - rbt-jira submit-patch -j jira-id: for jira-id, if a reviewboard entry
> is there, take latest patch from there, otherwise take patch by doing
> "git
> diff". After getting the patch, upload it to jira and mark the jira as
> patch available
>
> Both these commands are implemented. As an added bonus, you don't even have
> to provide jira id if your branch name is same as jira id :).
>
> Two more stretch goals I had were the following commands:
>
>
> - rbt-jira commit -j jira1 jira2 jira3: Only for committers. Should
> check each jira in the provided list, see if they are patch available,
> take
> latest patch from jira, commit it and push to trunk. Right now giving
> up on
> this because I'm hitting
> https://issues.apache.org/jira/browse/INFRA-6008.
> But will pick up again in free time and follow up with infra team.
> - rbt-jira clean: delete merged branches from your fork, fork's local
> clone, close submitted review requests, clean up any local storage used
> by
> other commands. Not essential right now.
>
> I can release the tool with version numbers, stand alone installation,
> single command access etc. but right now I want users (and myself) to use
> it while it's developing, so that issues might be caught early on.
>
>
> The usage of the tool is documented in the repo. Please use the tool and
> keep providing feedback. :). Special thanks to Yash for bringing the idea.
>
>
> Thanks and Regards
>