Re: Mandatory relocation of Sqoop git repository to gitbox

[Attila Szabó]

Hello everyone,

+1

@Szabi:
Thanks for owning the consensus process!!!

Cheers,
Attila

On Mon, Dec 10, 2018, 3:50 PM Fero Szabo  Hi Szabi,
>
> +1 from my side to get this done in the initial phase!
>
> Best Regards,
> Fero
>
> On Mon, Dec 10, 2018 at 2:29 PM Szabolcs Vasas  wrote:
>
> > Hi All,
> >
> > According to this
> > <
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201812.mbox/%3c6edbcae6-4eb9-6f61-beac-4198fd750...@apache.org%3E
> > >
> > email
> > the git-wip-us server, which hosts Apache Sqoop git repository too, is
> > going to be decommissioned soon and all the projects are going to be
> > migrated to gitbox.
> > For the detailed description of the planned change please refer to the
> > email linked, but the bottom line is that after the migration we are
> going
> > to be able to merge pull requests on the GitHub UI as well which will
> > greatly simplify our commit process.
> >
> > This relocation is mandatory however we have the option execute it in the
> > initial phase which would be great in my opinion because we could start
> > enjoying the benefits very soon.
> >
> > Please reply to this chain with your opinion because we need a consensus
> to
> > be able to start the migration in the initial phase.
> >
> > Thanks and regards,
> > Szabolcs
> >
>
>
> --
> *Ferenc Szabo* | Software Engineer
> t. (+361) 701 1201 <+361+701+1201>
> cloudera.com 
>
> [image: Cloudera] 
>
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> --
>

Re: Mandatory relocation of Sqoop git repository to gitbox

[Fero Szabo]

Hi Szabi,

+1 from my side to get this done in the initial phase!

Best Regards,
Fero

On Mon, Dec 10, 2018 at 2:29 PM Szabolcs Vasas  wrote:

> Hi All,
>
> According to this
> <
> http://mail-archives.apache.org/mod_mbox/incubator-general/201812.mbox/%3c6edbcae6-4eb9-6f61-beac-4198fd750...@apache.org%3E
> >
> email
> the git-wip-us server, which hosts Apache Sqoop git repository too, is
> going to be decommissioned soon and all the projects are going to be
> migrated to gitbox.
> For the detailed description of the planned change please refer to the
> email linked, but the bottom line is that after the migration we are going
> to be able to merge pull requests on the GitHub UI as well which will
> greatly simplify our commit process.
>
> This relocation is mandatory however we have the option execute it in the
> initial phase which would be great in my opinion because we could start
> enjoying the benefits very soon.
>
> Please reply to this chain with your opinion because we need a consensus to
> be able to start the migration in the initial phase.
>
> Thanks and regards,
> Szabolcs
>


-- 
*Ferenc Szabo* | Software Engineer
t. (+361) 701 1201 <+361+701+1201>
cloudera.com 

[image: Cloudera] 

[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 
--

Re: Review Request 62523: SQOOP-3237: Mainframe FTP transfer option to insert custom FTP commands prior to transfer

[Szabolcs Vasas]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62523/#review211139
---


Ship it!




Ship It!

- Szabolcs Vasas


On Dec. 10, 2018, 5:45 a.m., Chris Teoh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/62523/
> ---
> 
> (Updated Dec. 10, 2018, 5:45 a.m.)
> 
> 
> Review request for Sqoop.
> 
> 
> Bugs: SQOOP-3237
> https://issues.apache.org/jira/browse/SQOOP-3237
> 
> 
> Repository: sqoop-trunk
> 
> 
> Description
> ---
> 
> Added --ftpcmds command to allow comma separated list of FTP commands to send.
> 
> 
> Diffs
> -
> 
>   src/docs/user/import-mainframe.txt 3ecfb7e4 
>   src/java/org/apache/sqoop/SqoopOptions.java f06872f9 
>   src/java/org/apache/sqoop/mapreduce/mainframe/MainframeConfiguration.java 
> 9842daa6 
>   src/java/org/apache/sqoop/mapreduce/mainframe/MainframeImportJob.java 
> 90dc2ddd 
>   src/java/org/apache/sqoop/tool/MainframeImportTool.java fbc8c3db 
>   src/java/org/apache/sqoop/util/MainframeFTPClientUtils.java e7c48a6b 
>   
> src/test/org/apache/sqoop/mapreduce/mainframe/TestMainframeDatasetFTPRecordReader.java
>  502e6333 
>   src/test/org/apache/sqoop/tool/TestMainframeImportTool.java 00e57bd0 
>   src/test/org/apache/sqoop/util/TestMainframeFTPClientUtils.java fc6e56d6 
> 
> 
> Diff: https://reviews.apache.org/r/62523/diff/11/
> 
> 
> Testing
> ---
> 
> Unit tests.
> 
> 
> File Attachments
> 
> 
> SQOOP-3237-1.patch
>   
> https://reviews.apache.org/media/uploaded/files/2017/09/26/56041556-e355-4372-83ab-1bcc01680201__SQOOP-3237-1.patch
> 
> 
> Thanks,
> 
> Chris Teoh
> 
>

Re: Sqoop build infrastructure improvements

[Szabolcs Vasas]

Hi Attila,

Thanks for raising this, I think it is a great idea to migrate as soon as
possible, I have started a separate mail chain which can be used as a proof
of community consensus.

On Sun, Dec 9, 2018 at 9:48 PM Attila Szabó  wrote:

> Hello everyone,
>
> So if I'm not mistaken and according to the INFRA mail we've received
> during the weekend gitbox.apache.org is exactly what we wanted to have :
> Having both ASF commits and push privileges on Github side..
> We would just need to have an official consensus in the dev community (
> documented on the mail list), fire an INFRA Jira ticket, and after the
> merge update our site with the new "how to contribute" information.
>
> I think this would be a quite good timing for the Sqoop project as we're
> right now in the middle of these infrastructural reworks.
>
> Kind regards,
> Attila
>
> On Fri, Nov 30, 2018, 2:38 PM Szabolcs Vasas 
> > Thanks for the question, I think we should stick to the commit format we
> > had earlier so yes, we should go for squash and push.
> > The easiest solution could be to download the diff file instead of the
> > patch (e.g. https://github.com/apache/sqoop/pull/60.diff instead of
> > https://github.com/apache/sqoop/pull/60.patch) and that does the trick.
> >
> > The "This closes..." commit message just closes the PR but does not
> delete
> > the feature branch, asfgit most probably does not have delete permission
> > for these branches anyway.
> >
> >
> > On Fri, Nov 30, 2018 at 11:45 AM Attila Szabó  wrote:
> >
> > > 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"  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
> > > .
> > > 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ó 
> 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, 

Mandatory relocation of Sqoop git repository to gitbox

[Szabolcs Vasas]

Hi All,

According to this

email
the git-wip-us server, which hosts Apache Sqoop git repository too, is
going to be decommissioned soon and all the projects are going to be
migrated to gitbox.
For the detailed description of the planned change please refer to the
email linked, but the bottom line is that after the migration we are going
to be able to merge pull requests on the GitHub UI as well which will
greatly simplify our commit process.

This relocation is mandatory however we have the option execute it in the
initial phase which would be great in my opinion because we could start
enjoying the benefits very soon.

Please reply to this chain with your opinion because we need a consensus to
be able to start the migration in the initial phase.

Thanks and regards,
Szabolcs