Maybe I'm doing it wrong, but I've found pull requests to require more steps. I have to:
1. Fork the repo in GitHub 2. Create a branch with the changes (I usually do this step anyway though) 3. Push the branch to my forked repo in GitHub 4. Go to GitHub and click through a few things to create the pull request 5. (Ongoing) Ensure that my fork on GitHub is kept up-to-date On Fri, May 11, 2018 at 11:23 AM, Peter Bacsko <[email protected]> wrote: > Robert, is there anything particular that you don't like about pull > requests? Any clear disadvantages? > > On Thu, May 10, 2018 at 6:08 PM, Robert Kanter <[email protected]> > wrote: > > > In that case, +0 for pull requests. > > (I'm not the biggest fan of pull requests, but I've also not been doing a > > lot of contributing lately, so I won't stand in the way if that's what > > everyone wants) > > > > > > - Robert > > > > On Thu, May 10, 2018 at 8:55 AM, Peter Cseh <[email protected]> > wrote: > > > > > I've checked the Oozie pre-commit job config and there is a > pull-request > > > based trigger available. > > > I think it will be more reliable than the current way. There is no need > > for > > > the PreCommit-Admin job to grab all the attachments and coordinate on > > > what's new. > > > > > > > > > On Wed, May 9, 2018 at 11:11 PM, Peter Bacsko <[email protected]> > > > wrote: > > > > > > > I'm not sure how we can trigger a Jenkins build for pull requests, > but > > > > looking at this, it's possible: > > > > > > > > https://wiki.jenkins.io/display/JENKINS/GitHub+pull+ > > > request+builder+plugin > > > > > > > > We have to ask Jenkins admins to either install this (or similar) > > plugin, > > > > or configure existing ones so it deals with Oozie too. > > > > > > > > Anyway, +1 for pull requests. Definitely more convenient, rebasing is > > > > simple because merge conflicts can be resolved inside GitHub (also in > > > > command line). Retrieving the changes as a patch file is also super > > easy. > > > > > > > > Peter > > > > > > > > On Tue, May 8, 2018 at 7:55 PM, Robert Kanter <[email protected]> > > > wrote: > > > > > > > > > Is there a way to trigger > > > > > https://builds.apache.org/job/PreCommit-OOZIE-Build/ ( > > > > > https://builds.apache.org/job/PreCommit-Admin/) from a pull > request? > > > We > > > > > wouldn't want to lose the pre-commit Jenkins run. > > > > > > > > > > - Robert > > > > > > > > > > On Tue, May 8, 2018 at 7:25 AM, Andras Piros <[email protected]> > > > wrote: > > > > > > > > > > > Hi Geza, > > > > > > > > > > > > +1 on using GitHub pull requests instead of patches uploaded to > > > > > ReviewBoard > > > > > > / JIRA. PRs are the modern way of doing code reviews, integrating > > > > > changes, > > > > > > doing source code management in general. > > > > > > > > > > > > This step will lower the barrier newcomers face when trying to > > > > contribute > > > > > > for the first time, too. > > > > > > > > > > > > Andras > > > > > > > > > > > > On Tue, May 8, 2018 at 4:01 PM, Peter Cseh < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > Hi team Oozie! > > > > > > > > > > > > > > Many projects are using pull requests on Github instead of > > > uploading > > > > > > > patches to Jira. > > > > > > > Based on my experience with those projects, pull requests are > > > easier > > > > to > > > > > > > manage and less error prone than the current way of doing > commits > > > in > > > > > > Oozie. > > > > > > > > > > > > > > I would like to migrate Oozie to use pull requests instead of > > patch > > > > > files > > > > > > > in the next quarter if the community is up for that change. > > > > > > > I don't really see any downsides other than we'll have to > > resubmit > > > > some > > > > > > > patches for old jiras, which we'll have to do anyways due to > > > possible > > > > > > merge > > > > > > > conflicts. > > > > > > > The tooling and automation possibilities around pull requests > > will > > > > > > probably > > > > > > > meet all our needs. > > > > > > > > > > > > > > I don't know if we'd need an official vote for a change like > this > > > or > > > > > > > regular Jira is enough to track all the necessary changes. > Let's > > > see > > > > if > > > > > > > there are any objections against the general idea before going > > too > > > > much > > > > > > > into details. :) > > > > > > > > > > > > > > So... Any objections? > > > > > > > gp > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > *Peter Cseh *| Software Engineer > > > > > > > cloudera.com <https://www.cloudera.com> > > > > > > > > > > > > > > [image: Cloudera] <https://www.cloudera.com/> > > > > > > > > > > > > > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> > > > [image: > > > > > > > Cloudera on Facebook] <https://www.facebook.com/cloudera> > > [image: > > > > > > Cloudera > > > > > > > on LinkedIn] <https://www.linkedin.com/company/cloudera> > > > > > > > ------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > *Peter Cseh *| Software Engineer > > > cloudera.com <https://www.cloudera.com> > > > > > > [image: Cloudera] <https://www.cloudera.com/> > > > > > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > > Cloudera > > > on LinkedIn] <https://www.linkedin.com/company/cloudera> > > > ------------------------------ > > > > > >
