sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abraham Elmahrek <...@cloudera.com>
Subject Re: SQOOP-1367 Branch
Date Tue, 15 Jul 2014 18:08:32 GMT
Thanks man!


On Tue, Jul 15, 2014 at 10:54 AM, Jarek Jarcec Cecho <jarcec@apache.org>
wrote:

> Done:
>
>
> https://git-wip-us.apache.org/repos/asf?p=sqoop.git;a=shortlog;h=refs/heads/SQOOP-1367
>
> jarcec
>
> On Jul 15, 2014, at 10:37 AM, Abraham Elmahrek <abe@cloudera.com> wrote:
>
> > Thanks guys! Are there any committers that want to create the branch for
> > me? I suppose we could use its Jira number (SQOOP-1367) as its name.
> >
> >
> > On Mon, Jul 14, 2014 at 9:45 PM, David Robson <
> > David.Robson@software.dell.com> wrote:
> >
> >> Abe,
> >>
> >> I am not working on Sqoop2 - so while this won't affect me directly, I
> >> personally prefer new features to be done on a separate topic branch
> then
> >> merged in once they are stable - so I would +1 your idea.
> >>
> >> David
> >>
> >> -----Original Message-----
> >> From: Jarek Jarcec Cecho [mailto:jarcec@gmail.com] On Behalf Of Jarek
> >> Jarcec Cecho
> >> Sent: Tuesday, 15 July 2014 1:24 PM
> >> To: dev@sqoop.apache.org
> >> Subject: Re: SQOOP-1367 Branch
> >>
> >> + 0 from my side :-)
> >>
> >> Jarcec
> >>
> >> On Jul 14, 2014, at 2:32 PM, Hari Shreedharan <
> hshreedharan@cloudera.com>
> >> wrote:
> >>
> >>> +1 for me :)
> >>>
> >>>
> >>> Thanks,
> >>> Hari
> >>>
> >>>
> >>>
> >>>
> >>> On Jul 14, 2014, at 2:24 PM, Abraham Elmahrek <abe@cloudera.com>
> wrote:
> >>>
> >>>> We would likely comment out all the tests, which could bring about
> >>>> other forms of instability if there were other developers working on
> >>>> other things (without tests). I do believe that there will always be
> >>>> development on Sqoop2.
> >>>>
> >>>> Jarcec, is that a 0, -1, or +1?
> >>>>
> >>>> -Abe
> >>>>
> >>>>
> >>>> On Thu, Jul 10, 2014 at 8:48 PM, Jarek Jarcec Cecho
> >>>> <jarcec@apache.org>
> >>>> wrote:
> >>>>
> >>>>> I would see reason to create separate branch if we would be doing
> >>>>> some new and possibly breaking feature while working on smaller
> >>>>> features on the main line with possibility to cut release before
the
> >>>>> new big thing is done. As
> >>>>> SQOOP-1367 seems important enough to finish prior any additional
> >>>>> Sqoop 2 release nor other bigger features, I would be personally
> >>>>> fine with destabilizing the sqoop2 branch and simply do all the
> >> drastic changes there.
> >>>>>
> >>>>> Jarcec
> >>>>>
> >>>>> On Jul 10, 2014, at 8:03 PM, Gwen Shapira <gshapira@cloudera.com>
> >> wrote:
> >>>>>
> >>>>>> Good idea to work on drastic changes in a separate branch.
> >>>>>>
> >>>>>> Gwen
> >>>>>>
> >>>>>> On Jul 10, 2014 3:00 PM, "Abraham Elmahrek" <abe@apache.org>
wrote:
> >>>>>>
> >>>>>>> Dev folks,
> >>>>>>>
> >>>>>>> SQOOP-1367 requires drastic changes to the Sqoop2 code base
and
> >>>>>>> will
> >>>>> likely
> >>>>>>> bring some level of instability for a short period of time.
Could
> >>>>>>> we
> >>>>> create
> >>>>>>> a separate branch for SQOOP-1367 development? Here are a
few
> >>>>>>> reasons why this seems like a good idea:
> >>>>>>>
> >>>>>>> - Since releases are built from the "sqoop2" branch, it
seems
> >>>>>>> like it  should be stable.
> >>>>>>> - We could disable and enable tests freely as this branches
> >>>>>>> stability
> >>>>> is
> >>>>>>> not as important.
> >>>>>>> - Chunking work up will become a lot easier since we would
not
> >>>>>>> care if  this branch immediately works. This will make code
> >>>>>>> reviews much
> >>>>> easier.
> >>>>>>> - SQOOP-1367 is a core change to Sqoop2. It will touch several
> >>>>>>> files
> >>>>> and
> >>>>>>> reshape the shape of jobs.
> >>>>>>>
> >>>>>>> -Abe
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message