Hey Szabi, Thanks for the prompt response!
I've thought the repos are connected back and forth and the close PR is the official way. In case of we still stack to the patch file and git apply then commit and push approach. My only question in this case : Do we have any agreement on how we commit these PRs. I would vote for Squash and push, but of course I'm open for the discussion. BTW : Is "This closes" message deletes the branch automatically? On front of Github + Jira: I'm aware Github has the feature to connect with Jira so I'm pretty sure it doable. Also I'm not sure if any ASF project has done it ever, but I'll ask around in other communities. Cheers, Attila On Nov 30, 2018 11:03 AM, "Szabolcs Vasas" <va...@apache.org> wrote: Hi Attila, I think we won't be able to commit the pull requests on GitHub directly because our GitHub repo is just a mirror of the original Apache Sqoop repo <https://git-wip-us.apache.org/repos/asf/sqoop.git>. However the commit process is still simplified, the ASF GitHub Bot JIRA comment contains the patch download link (e.g. https://github.com/apache/sqoop/pull/60.patch) and the commit message (e.g. This closes #60) you need to include to close the pull request. The rest of the process remains the same, you need to apply the patch manually and push the commit to git-wip-us repo. Regarding the GitHub UI improvement: I am not sure GitHub provides such a feature, do you know an example repository where this is implemented? Regards, Szabolcs On Fri, Nov 30, 2018 at 3:21 AM Attila Szabó <mau...@apache.org> wrote: > Hi Szabi, > > First of all: > Big Kudos for the more mature gradle build! I think this is a great step > for the whole project! > > On the front of PRs: > I would only make it official if the user management / authorization > handling could be somehow automatically bound to the id.apache.org + > project privileges. > A good example: > Today I reviewed SQOOP-3396 but I would not had been able to merge it > because it seems on the Github project I do not have push / merge > privileges (regardless that I'm a Sqoop committer and also memeber of the > ASF group on github with my user). > So if we can somehow bound these things together, and the majority of the > ppl would like to use it instead of the Review Board then let it happen! > I'm fine with both tools until there's no difference between the Github and > ASF repos from user management POV. > > On the top of this: > I'm not sure if it belongs to our table, or the ASF INFRA team, but it > would be nice if the PRs and the JIRA tickets would be connected > automatically on the Github UI as well, and thus the navigation to > issues.apache.org would be easier! > > On the front of the gradle build: > I've found a smaller issue with clean+unittest within the same command. > I've opened a ticket (SQOOP-3415) and a PR (just the follow the new > standard) with a solution proposal. > > My2cents, > Attila > > On Wed, Nov 28, 2018 at 4:54 PM Szabolcs Vasas <va...@cloudera.com.invalid > > > wrote: > > > Dear Sqoop community, > > > > We have been working on quite a few exciting build infrastructure > > improvements recently, I am sending this email to summarize them. > > > > *Gradle can now execute all the Sqoop tests in a single JVM* > > This improvement makes the Gradle test tasks significantly faster since > we > > do not have to start up a new JVM for every test class. It also made > > possible to introduce fine grained test categories which were essential > to > > be able to parallelize the test execution in our CI systems. For more > > information please refer to COMPILING.txt > > <https://github.com/apache/sqoop/blob/trunk/COMPILING.txt>. > > > > *Apache Sqoop Jenkins job > > <https://builds.apache.org/job/Sqoop-hadoop200/> now builds and tests > with > > Gradle* > > Since our Gradle build became much more stable and faster it made sense > to > > reconfigure our Jenkins job to benefit from these improvements. The job > is > > faster now (~30 minutes instead of ~40) and it executes all of the tests > > which can be run without external RDBMS or cloud systems (while the old > Ant > > based job executed the unit test suite only). > > > > *Travis CI is enabled for Apache Sqoop* > > The new Travis CI job <https://travis-ci.org/apache/sqoop> now runs for > > every commit and every pull request on Apache Sqoop GitHub repository and > > it executes all of the tests except the Oracle third party test cases. > One > > of the biggest benefit of Travis CI is that it can be really easily > > configured for the individual forks as well so contributors get a well > > configured CI job for their own feature branches for free. For more > > information please refer to COMPILING.txt > > <https://github.com/apache/sqoop/blob/trunk/COMPILING.txt>. > > > > > > Since we have a CI job now which integrates very well with GitHub pull > > requests I suggest deprecating the old Review Board and patch file based > > contribution process and use pull requests in the future. We had a mail > > chain about the same proposal last year and it seemed that the community > > was happy about the idea so I think we can evaluate it for some time and > if > > everything goes well we can update our how to contribute wiki. > > > > Feel free to reply to this chain with your questions and suggestions on > the > > above! > > > > Regards, > > Szabolcs > > <http://www.cloudera.com>
