Re: Migrating Heron code to Apache

[Karthik Ramasamy]

+1 for Taylor's approach as well.

On Wed, Nov 8, 2017 at 10:57 AM, Bill Graham  wrote:

> +1 for that approach, thanks Taylor.
>
>
>
> On Wed, Nov 8, 2017 at 10:47 AM, P. Taylor Goetz 
> wrote:
>
> > Another thing to keep in mind is that non-Apache release artifacts cannot
> > be hosted on ASF infrastructure. Even so, non-Apache releases can be cut
> > from an ASF-hosted git repository. Non-Apache releases also need to be
> > clearly labeled as such.
> >
> > In terms of moving from “com.twitter” to “org.apache” maven group names
> > and source code package names, I would highly recommend making the maven
> > group name change as well as changing the package names.
> >
> > As Jerry pointed out, Storm waited a long time to change package names to
> > “org.apache.storm” (maven group name change was immediate). One of the
> > reasons we were able to do this is because the original package name was
> > “backtype” as opposed to “com.backtype”. I wouldn’t be surprised if there
> > were IPMC pushback on making an Apache release with the “com.twitter”
> > package prefix. You’d likely need a compelling justification for not
> making
> > the change.
> >
> > In short, my recommendations:
> >
> > 1. Move to Apache git — you can still do non-Apache releases
> > 2. Change groupId/package prefixes to “org.apache.*” prior to attempting
> > an Apache release.
> >
> > -Taylor
> >
> >
> > > On Nov 7, 2017, at 7:32 PM, Julien Le Dem 
> > wrote:
> > >
> > > Sorry for the late reply.
> > > +1 to moving to apache git first.
> > > +1 on using gitbox so that the github repo is writable. That should
> > > simplify a lot of things.
> > > When we migrated parquet, we first moved the code to apache git and
> only
> > > later renamed packages to the new org.apache.parquet namespace.
> > > For java artifacts. I'd recommend renaming packages and maven group in
> > the
> > > same release to avoid weird dependency conflicts (you don't want 2
> maven
> > > artifacts with different coordinates but same class name). If you
> follow
> > > this convention, you force yourself to post org.apache maven artifacts
> > only
> > > once you rename your packages.
> > > We still did a few twitter releases while the projects was not ready
> yet
> > to
> > > make apache release (updating the build, notice, etc). It is ok but it
> > must
> > > be very clear that those are not official apache releases. Official
> > Apache
> > > releases must be voted on by the PMC (and the IPMC in the incubator).
> And
> > > you need to make sure you're still mking progress towards apache
> official
> > > releases which is the point of the incubation.
> > >
> > >
> > >
> > > On Sun, Oct 29, 2017 at 8:27 PM, Jacques Nadeau 
> > wrote:
> > >
> > >> I don't believe the location of the code influences the type of
> release
> > >> allowed. For example, I believe the Parquet project to did a
> non-Apache
> > >> release after migrating. Maybe Julien can confirm that. Or
> Jake/another
> > can
> > >> reconfirm/refute my memory.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Sun, Oct 29, 2017 at 9:24 AM, Bill Graham 
> > wrote:
> > >>
> > >>> Jacques, I was under the impression that once the code was imported
> to
> > >>> apache, releases had to be apache releases. This would require 1 and
> a
> > >>> number of other changes. Is that not the case? The motivation for
> > doing 1
> > >>> first was so we could continue to cut releases as needed during that
> > >>> effort.
> > >>>
> > >>> On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau 
> > >> wrote:
> > >>>
> >  I'm -0 on plan.
> > 
> >  Why not just import code then do changes 1 and 2 after 3? Just seems
> > >> like
> >  getting 3 done is a key blocking item on forward progress of the
> > >>> community.
> > 
> >  On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni" 
> > >> wrote:
> > 
> > > +1
> > >
> > > On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham  >
> >  wrote:
> > >
> > >> Any other comments on this proposal from Heron developers? The
> next
> > > podling
> > >> report is due on Wednesday so we should address our plan.
> > >>
> > >> On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament <
> > >>> johndam...@apache.org>
> > >> wrote:
> > >>
> > >>> If you do in fact want to use gitbox (which allows you to have
> > >>> github
> > >>> writable repos), infra will need to be made an admin on your
> > > organization
> > >>> temporarily to do the migration.
> > >>>
> > >>> Many new projects are doing this, so it's not uncommon to just
> > >> use
> > > gitbox
> > >>> since you're already on github.
> > >>>
> > >>> John
> > >>>
> > >>> On 2017-10-19 13:20, Brian Hatfield 
> > >> wrote:
> >  Thank you both for the info :-) I had not realized 

Re: Migrating Heron code to Apache

[Bill Graham]

+1 for that approach, thanks Taylor.



On Wed, Nov 8, 2017 at 10:47 AM, P. Taylor Goetz  wrote:

> Another thing to keep in mind is that non-Apache release artifacts cannot
> be hosted on ASF infrastructure. Even so, non-Apache releases can be cut
> from an ASF-hosted git repository. Non-Apache releases also need to be
> clearly labeled as such.
>
> In terms of moving from “com.twitter” to “org.apache” maven group names
> and source code package names, I would highly recommend making the maven
> group name change as well as changing the package names.
>
> As Jerry pointed out, Storm waited a long time to change package names to
> “org.apache.storm” (maven group name change was immediate). One of the
> reasons we were able to do this is because the original package name was
> “backtype” as opposed to “com.backtype”. I wouldn’t be surprised if there
> were IPMC pushback on making an Apache release with the “com.twitter”
> package prefix. You’d likely need a compelling justification for not making
> the change.
>
> In short, my recommendations:
>
> 1. Move to Apache git — you can still do non-Apache releases
> 2. Change groupId/package prefixes to “org.apache.*” prior to attempting
> an Apache release.
>
> -Taylor
>
>
> > On Nov 7, 2017, at 7:32 PM, Julien Le Dem 
> wrote:
> >
> > Sorry for the late reply.
> > +1 to moving to apache git first.
> > +1 on using gitbox so that the github repo is writable. That should
> > simplify a lot of things.
> > When we migrated parquet, we first moved the code to apache git and only
> > later renamed packages to the new org.apache.parquet namespace.
> > For java artifacts. I'd recommend renaming packages and maven group in
> the
> > same release to avoid weird dependency conflicts (you don't want 2 maven
> > artifacts with different coordinates but same class name). If you follow
> > this convention, you force yourself to post org.apache maven artifacts
> only
> > once you rename your packages.
> > We still did a few twitter releases while the projects was not ready yet
> to
> > make apache release (updating the build, notice, etc). It is ok but it
> must
> > be very clear that those are not official apache releases. Official
> Apache
> > releases must be voted on by the PMC (and the IPMC in the incubator). And
> > you need to make sure you're still mking progress towards apache official
> > releases which is the point of the incubation.
> >
> >
> >
> > On Sun, Oct 29, 2017 at 8:27 PM, Jacques Nadeau 
> wrote:
> >
> >> I don't believe the location of the code influences the type of release
> >> allowed. For example, I believe the Parquet project to did a non-Apache
> >> release after migrating. Maybe Julien can confirm that. Or Jake/another
> can
> >> reconfirm/refute my memory.
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Oct 29, 2017 at 9:24 AM, Bill Graham 
> wrote:
> >>
> >>> Jacques, I was under the impression that once the code was imported to
> >>> apache, releases had to be apache releases. This would require 1 and a
> >>> number of other changes. Is that not the case? The motivation for
> doing 1
> >>> first was so we could continue to cut releases as needed during that
> >>> effort.
> >>>
> >>> On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau 
> >> wrote:
> >>>
>  I'm -0 on plan.
> 
>  Why not just import code then do changes 1 and 2 after 3? Just seems
> >> like
>  getting 3 done is a key blocking item on forward progress of the
> >>> community.
> 
>  On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni" 
> >> wrote:
> 
> > +1
> >
> > On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham 
>  wrote:
> >
> >> Any other comments on this proposal from Heron developers? The next
> > podling
> >> report is due on Wednesday so we should address our plan.
> >>
> >> On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament <
> >>> johndam...@apache.org>
> >> wrote:
> >>
> >>> If you do in fact want to use gitbox (which allows you to have
> >>> github
> >>> writable repos), infra will need to be made an admin on your
> > organization
> >>> temporarily to do the migration.
> >>>
> >>> Many new projects are doing this, so it's not uncommon to just
> >> use
> > gitbox
> >>> since you're already on github.
> >>>
> >>> John
> >>>
> >>> On 2017-10-19 13:20, Brian Hatfield 
> >> wrote:
>  Thank you both for the info :-) I had not realized it would
> >> just
> >>> be
>  re-homed in a different Github org. Thanks!
> 
>  Brian
> 
>  On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham <
>  billgra...@gmail.com>
> >>> wrote:
> 
> > Right, it would still be on github, just at apache/heron
> >>> instead
>  of
> > twitter/heron.
> >
> > On 

Re: Migrating Heron code to Apache

[P. Taylor Goetz]

Another thing to keep in mind is that non-Apache release artifacts cannot be 
hosted on ASF infrastructure. Even so, non-Apache releases can be cut from an 
ASF-hosted git repository. Non-Apache releases also need to be clearly labeled 
as such.

In terms of moving from “com.twitter” to “org.apache” maven group names and 
source code package names, I would highly recommend making the maven group name 
change as well as changing the package names.

As Jerry pointed out, Storm waited a long time to change package names to 
“org.apache.storm” (maven group name change was immediate). One of the reasons 
we were able to do this is because the original package name was “backtype” as 
opposed to “com.backtype”. I wouldn’t be surprised if there were IPMC pushback 
on making an Apache release with the “com.twitter” package prefix. You’d likely 
need a compelling justification for not making the change.

In short, my recommendations:

1. Move to Apache git — you can still do non-Apache releases
2. Change groupId/package prefixes to “org.apache.*” prior to attempting an 
Apache release.

-Taylor


> On Nov 7, 2017, at 7:32 PM, Julien Le Dem  wrote:
> 
> Sorry for the late reply.
> +1 to moving to apache git first.
> +1 on using gitbox so that the github repo is writable. That should
> simplify a lot of things.
> When we migrated parquet, we first moved the code to apache git and only
> later renamed packages to the new org.apache.parquet namespace.
> For java artifacts. I'd recommend renaming packages and maven group in the
> same release to avoid weird dependency conflicts (you don't want 2 maven
> artifacts with different coordinates but same class name). If you follow
> this convention, you force yourself to post org.apache maven artifacts only
> once you rename your packages.
> We still did a few twitter releases while the projects was not ready yet to
> make apache release (updating the build, notice, etc). It is ok but it must
> be very clear that those are not official apache releases. Official Apache
> releases must be voted on by the PMC (and the IPMC in the incubator). And
> you need to make sure you're still mking progress towards apache official
> releases which is the point of the incubation.
> 
> 
> 
> On Sun, Oct 29, 2017 at 8:27 PM, Jacques Nadeau  wrote:
> 
>> I don't believe the location of the code influences the type of release
>> allowed. For example, I believe the Parquet project to did a non-Apache
>> release after migrating. Maybe Julien can confirm that. Or Jake/another can
>> reconfirm/refute my memory.
>> 
>> 
>> 
>> 
>> 
>> On Sun, Oct 29, 2017 at 9:24 AM, Bill Graham  wrote:
>> 
>>> Jacques, I was under the impression that once the code was imported to
>>> apache, releases had to be apache releases. This would require 1 and a
>>> number of other changes. Is that not the case? The motivation for doing 1
>>> first was so we could continue to cut releases as needed during that
>>> effort.
>>> 
>>> On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau 
>> wrote:
>>> 
 I'm -0 on plan.
 
 Why not just import code then do changes 1 and 2 after 3? Just seems
>> like
 getting 3 done is a key blocking item on forward progress of the
>>> community.
 
 On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni" 
>> wrote:
 
> +1
> 
> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham 
 wrote:
> 
>> Any other comments on this proposal from Heron developers? The next
> podling
>> report is due on Wednesday so we should address our plan.
>> 
>> On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament <
>>> johndam...@apache.org>
>> wrote:
>> 
>>> If you do in fact want to use gitbox (which allows you to have
>>> github
>>> writable repos), infra will need to be made an admin on your
> organization
>>> temporarily to do the migration.
>>> 
>>> Many new projects are doing this, so it's not uncommon to just
>> use
> gitbox
>>> since you're already on github.
>>> 
>>> John
>>> 
>>> On 2017-10-19 13:20, Brian Hatfield 
>> wrote:
 Thank you both for the info :-) I had not realized it would
>> just
>>> be
 re-homed in a different Github org. Thanks!
 
 Brian
 
 On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham <
 billgra...@gmail.com>
>>> wrote:
 
> Right, it would still be on github, just at apache/heron
>>> instead
 of
> twitter/heron.
> 
> On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell <
 jfarr...@apache.org>
>>> wrote:
> 
>> Apache git can also refer to the Github Apache org as a
>>> number
 of
> projects
>> are running in that fashion. They key is that the code has
>>> been
>>> imported
>> over to the Apache Infra 

Re: Migrating Heron code to Apache

[Julien Le Dem]

Sorry for the late reply.
+1 to moving to apache git first.
+1 on using gitbox so that the github repo is writable. That should
simplify a lot of things.
When we migrated parquet, we first moved the code to apache git and only
later renamed packages to the new org.apache.parquet namespace.
For java artifacts. I'd recommend renaming packages and maven group in the
same release to avoid weird dependency conflicts (you don't want 2 maven
artifacts with different coordinates but same class name). If you follow
this convention, you force yourself to post org.apache maven artifacts only
once you rename your packages.
We still did a few twitter releases while the projects was not ready yet to
make apache release (updating the build, notice, etc). It is ok but it must
be very clear that those are not official apache releases. Official Apache
releases must be voted on by the PMC (and the IPMC in the incubator). And
you need to make sure you're still mking progress towards apache official
releases which is the point of the incubation.



On Sun, Oct 29, 2017 at 8:27 PM, Jacques Nadeau  wrote:

> I don't believe the location of the code influences the type of release
> allowed. For example, I believe the Parquet project to did a non-Apache
> release after migrating. Maybe Julien can confirm that. Or Jake/another can
> reconfirm/refute my memory.
>
>
>
>
>
> On Sun, Oct 29, 2017 at 9:24 AM, Bill Graham  wrote:
>
> > Jacques, I was under the impression that once the code was imported to
> > apache, releases had to be apache releases. This would require 1 and a
> > number of other changes. Is that not the case? The motivation for doing 1
> > first was so we could continue to cut releases as needed during that
> > effort.
> >
> > On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau 
> wrote:
> >
> > > I'm -0 on plan.
> > >
> > > Why not just import code then do changes 1 and 2 after 3? Just seems
> like
> > > getting 3 done is a key blocking item on forward progress of the
> > community.
> > >
> > > On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni" 
> wrote:
> > >
> > > > +1
> > > >
> > > > On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham 
> > > wrote:
> > > >
> > > > > Any other comments on this proposal from Heron developers? The next
> > > > podling
> > > > > report is due on Wednesday so we should address our plan.
> > > > >
> > > > > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament <
> > johndam...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > If you do in fact want to use gitbox (which allows you to have
> > github
> > > > > > writable repos), infra will need to be made an admin on your
> > > > organization
> > > > > > temporarily to do the migration.
> > > > > >
> > > > > > Many new projects are doing this, so it's not uncommon to just
> use
> > > > gitbox
> > > > > > since you're already on github.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On 2017-10-19 13:20, Brian Hatfield 
> wrote:
> > > > > > > Thank you both for the info :-) I had not realized it would
> just
> > be
> > > > > > > re-homed in a different Github org. Thanks!
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham <
> > > billgra...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Right, it would still be on github, just at apache/heron
> > instead
> > > of
> > > > > > > > twitter/heron.
> > > > > > > >
> > > > > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell <
> > > jfarr...@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Apache git can also refer to the Github Apache org as a
> > number
> > > of
> > > > > > > > projects
> > > > > > > > > are running in that fashion. They key is that the code has
> > been
> > > > > > imported
> > > > > > > > > over to the Apache Infra owned/managed infrastructure
> > > > > > > > >
> > > > > > > > > -Jake
> > > > > > > > >
> > > > > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> > > > > > bmhatfi...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> Silly question - and apologies if this has already been
> > > > discussed
> > > > > -
> > > > > > but
> > > > > > > > is
> > > > > > > > >> #3 (Migrate the code to Apache git) required? From my
> > > > perspective
> > > > > > Github
> > > > > > > > >> is
> > > > > > > > >> much more preferable as it's where nearly every other open
> > > > source
> > > > > > > > codebase
> > > > > > > > >> I interact with is, and the UI is very friendly to
> > newcomers.
> > > > > > > > >>
> > > > > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
> > > > > billgra...@gmail.com
> > > > > > >
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >> > Hi,
> > > > > > > > >> >
> > > > > > > > >> > In LEGAL-339 <
> > > https://issues.apache.org/jira/browse/LEGAL-339
> > > > >
> > > > > > it was
> > > > > > > > >> > concluded that 

Re: Migrating Heron code to Apache

[Jacques Nadeau]

I don't believe the location of the code influences the type of release
allowed. For example, I believe the Parquet project to did a non-Apache
release after migrating. Maybe Julien can confirm that. Or Jake/another can
reconfirm/refute my memory.





On Sun, Oct 29, 2017 at 9:24 AM, Bill Graham  wrote:

> Jacques, I was under the impression that once the code was imported to
> apache, releases had to be apache releases. This would require 1 and a
> number of other changes. Is that not the case? The motivation for doing 1
> first was so we could continue to cut releases as needed during that
> effort.
>
> On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau  wrote:
>
> > I'm -0 on plan.
> >
> > Why not just import code then do changes 1 and 2 after 3? Just seems like
> > getting 3 done is a key blocking item on forward progress of the
> community.
> >
> > On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni"  wrote:
> >
> > > +1
> > >
> > > On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham 
> > wrote:
> > >
> > > > Any other comments on this proposal from Heron developers? The next
> > > podling
> > > > report is due on Wednesday so we should address our plan.
> > > >
> > > > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament <
> johndam...@apache.org>
> > > > wrote:
> > > >
> > > > > If you do in fact want to use gitbox (which allows you to have
> github
> > > > > writable repos), infra will need to be made an admin on your
> > > organization
> > > > > temporarily to do the migration.
> > > > >
> > > > > Many new projects are doing this, so it's not uncommon to just use
> > > gitbox
> > > > > since you're already on github.
> > > > >
> > > > > John
> > > > >
> > > > > On 2017-10-19 13:20, Brian Hatfield  wrote:
> > > > > > Thank you both for the info :-) I had not realized it would just
> be
> > > > > > re-homed in a different Github org. Thanks!
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham <
> > billgra...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Right, it would still be on github, just at apache/heron
> instead
> > of
> > > > > > > twitter/heron.
> > > > > > >
> > > > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell <
> > jfarr...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > Apache git can also refer to the Github Apache org as a
> number
> > of
> > > > > > > projects
> > > > > > > > are running in that fashion. They key is that the code has
> been
> > > > > imported
> > > > > > > > over to the Apache Infra owned/managed infrastructure
> > > > > > > >
> > > > > > > > -Jake
> > > > > > > >
> > > > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> > > > > bmhatfi...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Silly question - and apologies if this has already been
> > > discussed
> > > > -
> > > > > but
> > > > > > > is
> > > > > > > >> #3 (Migrate the code to Apache git) required? From my
> > > perspective
> > > > > Github
> > > > > > > >> is
> > > > > > > >> much more preferable as it's where nearly every other open
> > > source
> > > > > > > codebase
> > > > > > > >> I interact with is, and the UI is very friendly to
> newcomers.
> > > > > > > >>
> > > > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
> > > > billgra...@gmail.com
> > > > > >
> > > > > > > >> wrote:
> > > > > > > >>
> > > > > > > >> > Hi,
> > > > > > > >> >
> > > > > > > >> > In LEGAL-339 <
> > https://issues.apache.org/jira/browse/LEGAL-339
> > > >
> > > > > it was
> > > > > > > >> > concluded that we can in fact move the code to Apache git
> > and
> > > > cut
> > > > > > > Apache
> > > > > > > >> > releases without the SGA. I propose we move forward on
> > that. I
> > > > > suggest
> > > > > > > >> the
> > > > > > > >> > following plan:
> > > > > > > >> >
> > > > > > > >> > 1.a Refactor all Heron build dependencies (mainly c++
> libs)
> > to
> > > > be
> > > > > > > >> fetched
> > > > > > > >> > at build time and not committed in the repo. (#2092
> > > > > > > >> > )
> > > > > > > >> > 1.b Refactor the bazel checkstyles to support both the
> > Twitter
> > > > > > > copyright
> > > > > > > >> > (for existing code) and the Apache copyright (for new code
> > > after
> > > > > the
> > > > > > > >> > migration).
> > > > > > > >> > 2. Cut the last non-Apache release.
> > > > > > > >> > 3. Migrate the code to Apache git
> > > > > > > >> > 4. Add incubation disclaimer
> > > > > > > >> > 5. Cut the first Apache release.
> > > > > > > >> >
> > > > > > > >> > What do folks think of that plan? Item's 1a and 1b can
> > happen
> > > in
> > > > > > > >> parallel,
> > > > > > > >> > as could item 2 actually. There will surely be more
> smaller
> > > > > items, but
> > > > > > > >> > those are the big ones as I see it. Please chime in if
> I've
> > > > > overlooked
> > > > > > > >> > anything major.

Re: Migrating Heron code to Apache

[Jerry Peng]

As in terms of the order execution.  I am not a lawyer, but I think
you can still cut releases with packages in com.twitter even after in
it is in apache git.  In the early days of Apache Storm, all the Java
code was under org.backtype, however releases were still cut without a
problem.  If this is the case, I would suggest, we move all the code
to apache git first (step 3) and then we can work on the other changes
such as migrating the package names and etc.  By moving the project,
to apache git, Heron will look more like a legitimate ASF project
sooner.

I also have a question.  Do we need to include the twitter copyright
on existing files?  Many ASF projects that have been donated by
companies do not have a copyright in the header for the respective
companies.

On Sun, Oct 29, 2017 at 9:54 AM, Jerry Peng  wrote:
> Hello all,
>
> I strongly agree with Bill on migrating the code base to org.apache.
> This will attract more developers and automatically fix issues
> involving copyrights and headers that we don't need to waste our time
> dealing with.  Heron, as an open source project, is in a state of
> limbo. Developers are confused to whether Heron is indeed in ASF or
> not, and this could dissuade potential developers from investing in
> the project.  There has been talk of Heron joining Apache for a very
> long time, and I think people are starting to wonder if there is
> something wrong with Heron that is still causing it to not officially
> look like an ASF project.  The most important thing to the success of
> an ASF, or any open source project, is the community around the
> project.  The longer we wait on this, more and more potential
> developers and contributors might turn away. Thus, I think we should
> push this through ASAP.
>
> Best,
>
> Jerry
>
> On Sun, Oct 29, 2017 at 7:41 AM, Jacques Nadeau  wrote:
>> I'm -0 on plan.
>>
>> Why not just import code then do changes 1 and 2 after 3? Just seems like
>> getting 3 done is a key blocking item on forward progress of the community.
>>
>> On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni"  wrote:
>>
>>> +1
>>>
>>> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham  wrote:
>>>
>>> > Any other comments on this proposal from Heron developers? The next
>>> podling
>>> > report is due on Wednesday so we should address our plan.
>>> >
>>> > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
>>> > wrote:
>>> >
>>> > > If you do in fact want to use gitbox (which allows you to have github
>>> > > writable repos), infra will need to be made an admin on your
>>> organization
>>> > > temporarily to do the migration.
>>> > >
>>> > > Many new projects are doing this, so it's not uncommon to just use
>>> gitbox
>>> > > since you're already on github.
>>> > >
>>> > > John
>>> > >
>>> > > On 2017-10-19 13:20, Brian Hatfield  wrote:
>>> > > > Thank you both for the info :-) I had not realized it would just be
>>> > > > re-homed in a different Github org. Thanks!
>>> > > >
>>> > > > Brian
>>> > > >
>>> > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham 
>>> > > wrote:
>>> > > >
>>> > > > > Right, it would still be on github, just at apache/heron instead of
>>> > > > > twitter/heron.
>>> > > > >
>>> > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell 
>>> > > wrote:
>>> > > > >
>>> > > > > > Apache git can also refer to the Github Apache org as a number of
>>> > > > > projects
>>> > > > > > are running in that fashion. They key is that the code has been
>>> > > imported
>>> > > > > > over to the Apache Infra owned/managed infrastructure
>>> > > > > >
>>> > > > > > -Jake
>>> > > > > >
>>> > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
>>> > > bmhatfi...@gmail.com>
>>> > > > > > wrote:
>>> > > > > >
>>> > > > > >> Silly question - and apologies if this has already been
>>> discussed
>>> > -
>>> > > but
>>> > > > > is
>>> > > > > >> #3 (Migrate the code to Apache git) required? From my
>>> perspective
>>> > > Github
>>> > > > > >> is
>>> > > > > >> much more preferable as it's where nearly every other open
>>> source
>>> > > > > codebase
>>> > > > > >> I interact with is, and the UI is very friendly to newcomers.
>>> > > > > >>
>>> > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
>>> > billgra...@gmail.com
>>> > > >
>>> > > > > >> wrote:
>>> > > > > >>
>>> > > > > >> > Hi,
>>> > > > > >> >
>>> > > > > >> > In LEGAL-339 >> >
>>> > > it was
>>> > > > > >> > concluded that we can in fact move the code to Apache git and
>>> > cut
>>> > > > > Apache
>>> > > > > >> > releases without the SGA. I propose we move forward on that. I
>>> > > suggest
>>> > > > > >> the
>>> > > > > >> > following plan:
>>> > > > > >> >
>>> > > > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to
>>> > be
>>> > > > > >> fetched
>>> > > > > >> > at 

Re: Migrating Heron code to Apache

[Jerry Peng]

Hello all,

I strongly agree with Bill on migrating the code base to org.apache.
This will attract more developers and automatically fix issues
involving copyrights and headers that we don't need to waste our time
dealing with.  Heron, as an open source project, is in a state of
limbo. Developers are confused to whether Heron is indeed in ASF or
not, and this could dissuade potential developers from investing in
the project.  There has been talk of Heron joining Apache for a very
long time, and I think people are starting to wonder if there is
something wrong with Heron that is still causing it to not officially
look like an ASF project.  The most important thing to the success of
an ASF, or any open source project, is the community around the
project.  The longer we wait on this, more and more potential
developers and contributors might turn away. Thus, I think we should
push this through ASAP.

Best,

Jerry

On Sun, Oct 29, 2017 at 7:41 AM, Jacques Nadeau  wrote:
> I'm -0 on plan.
>
> Why not just import code then do changes 1 and 2 after 3? Just seems like
> getting 3 done is a key blocking item on forward progress of the community.
>
> On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni"  wrote:
>
>> +1
>>
>> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham  wrote:
>>
>> > Any other comments on this proposal from Heron developers? The next
>> podling
>> > report is due on Wednesday so we should address our plan.
>> >
>> > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
>> > wrote:
>> >
>> > > If you do in fact want to use gitbox (which allows you to have github
>> > > writable repos), infra will need to be made an admin on your
>> organization
>> > > temporarily to do the migration.
>> > >
>> > > Many new projects are doing this, so it's not uncommon to just use
>> gitbox
>> > > since you're already on github.
>> > >
>> > > John
>> > >
>> > > On 2017-10-19 13:20, Brian Hatfield  wrote:
>> > > > Thank you both for the info :-) I had not realized it would just be
>> > > > re-homed in a different Github org. Thanks!
>> > > >
>> > > > Brian
>> > > >
>> > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham 
>> > > wrote:
>> > > >
>> > > > > Right, it would still be on github, just at apache/heron instead of
>> > > > > twitter/heron.
>> > > > >
>> > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell 
>> > > wrote:
>> > > > >
>> > > > > > Apache git can also refer to the Github Apache org as a number of
>> > > > > projects
>> > > > > > are running in that fashion. They key is that the code has been
>> > > imported
>> > > > > > over to the Apache Infra owned/managed infrastructure
>> > > > > >
>> > > > > > -Jake
>> > > > > >
>> > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
>> > > bmhatfi...@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > >> Silly question - and apologies if this has already been
>> discussed
>> > -
>> > > but
>> > > > > is
>> > > > > >> #3 (Migrate the code to Apache git) required? From my
>> perspective
>> > > Github
>> > > > > >> is
>> > > > > >> much more preferable as it's where nearly every other open
>> source
>> > > > > codebase
>> > > > > >> I interact with is, and the UI is very friendly to newcomers.
>> > > > > >>
>> > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
>> > billgra...@gmail.com
>> > > >
>> > > > > >> wrote:
>> > > > > >>
>> > > > > >> > Hi,
>> > > > > >> >
>> > > > > >> > In LEGAL-339 > >
>> > > it was
>> > > > > >> > concluded that we can in fact move the code to Apache git and
>> > cut
>> > > > > Apache
>> > > > > >> > releases without the SGA. I propose we move forward on that. I
>> > > suggest
>> > > > > >> the
>> > > > > >> > following plan:
>> > > > > >> >
>> > > > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to
>> > be
>> > > > > >> fetched
>> > > > > >> > at build time and not committed in the repo. (#2092
>> > > > > >> > )
>> > > > > >> > 1.b Refactor the bazel checkstyles to support both the Twitter
>> > > > > copyright
>> > > > > >> > (for existing code) and the Apache copyright (for new code
>> after
>> > > the
>> > > > > >> > migration).
>> > > > > >> > 2. Cut the last non-Apache release.
>> > > > > >> > 3. Migrate the code to Apache git
>> > > > > >> > 4. Add incubation disclaimer
>> > > > > >> > 5. Cut the first Apache release.
>> > > > > >> >
>> > > > > >> > What do folks think of that plan? Item's 1a and 1b can happen
>> in
>> > > > > >> parallel,
>> > > > > >> > as could item 2 actually. There will surely be more smaller
>> > > items, but
>> > > > > >> > those are the big ones as I see it. Please chime in if I've
>> > > overlooked
>> > > > > >> > anything major.
>> > > > > >> >
>> > > > > >> > thanks,
>> > > > > >> > Bill
>> > > > > >> >
>> > > > > >>
>> > > > > >
>> > > 

Re: Migrating Heron code to Apache

[Bill Graham]

Jacques, I was under the impression that once the code was imported to
apache, releases had to be apache releases. This would require 1 and a
number of other changes. Is that not the case? The motivation for doing 1
first was so we could continue to cut releases as needed during that
effort.

On Sun, Oct 29, 2017 at 7:41 AM Jacques Nadeau  wrote:

> I'm -0 on plan.
>
> Why not just import code then do changes 1 and 2 after 3? Just seems like
> getting 3 done is a key blocking item on forward progress of the community.
>
> On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni"  wrote:
>
> > +1
> >
> > On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham 
> wrote:
> >
> > > Any other comments on this proposal from Heron developers? The next
> > podling
> > > report is due on Wednesday so we should address our plan.
> > >
> > > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
> > > wrote:
> > >
> > > > If you do in fact want to use gitbox (which allows you to have github
> > > > writable repos), infra will need to be made an admin on your
> > organization
> > > > temporarily to do the migration.
> > > >
> > > > Many new projects are doing this, so it's not uncommon to just use
> > gitbox
> > > > since you're already on github.
> > > >
> > > > John
> > > >
> > > > On 2017-10-19 13:20, Brian Hatfield  wrote:
> > > > > Thank you both for the info :-) I had not realized it would just be
> > > > > re-homed in a different Github org. Thanks!
> > > > >
> > > > > Brian
> > > > >
> > > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham <
> billgra...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Right, it would still be on github, just at apache/heron instead
> of
> > > > > > twitter/heron.
> > > > > >
> > > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell <
> jfarr...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > Apache git can also refer to the Github Apache org as a number
> of
> > > > > > projects
> > > > > > > are running in that fashion. They key is that the code has been
> > > > imported
> > > > > > > over to the Apache Infra owned/managed infrastructure
> > > > > > >
> > > > > > > -Jake
> > > > > > >
> > > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> > > > bmhatfi...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Silly question - and apologies if this has already been
> > discussed
> > > -
> > > > but
> > > > > > is
> > > > > > >> #3 (Migrate the code to Apache git) required? From my
> > perspective
> > > > Github
> > > > > > >> is
> > > > > > >> much more preferable as it's where nearly every other open
> > source
> > > > > > codebase
> > > > > > >> I interact with is, and the UI is very friendly to newcomers.
> > > > > > >>
> > > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
> > > billgra...@gmail.com
> > > > >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > Hi,
> > > > > > >> >
> > > > > > >> > In LEGAL-339 <
> https://issues.apache.org/jira/browse/LEGAL-339
> > >
> > > > it was
> > > > > > >> > concluded that we can in fact move the code to Apache git
> and
> > > cut
> > > > > > Apache
> > > > > > >> > releases without the SGA. I propose we move forward on
> that. I
> > > > suggest
> > > > > > >> the
> > > > > > >> > following plan:
> > > > > > >> >
> > > > > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs)
> to
> > > be
> > > > > > >> fetched
> > > > > > >> > at build time and not committed in the repo. (#2092
> > > > > > >> > )
> > > > > > >> > 1.b Refactor the bazel checkstyles to support both the
> Twitter
> > > > > > copyright
> > > > > > >> > (for existing code) and the Apache copyright (for new code
> > after
> > > > the
> > > > > > >> > migration).
> > > > > > >> > 2. Cut the last non-Apache release.
> > > > > > >> > 3. Migrate the code to Apache git
> > > > > > >> > 4. Add incubation disclaimer
> > > > > > >> > 5. Cut the first Apache release.
> > > > > > >> >
> > > > > > >> > What do folks think of that plan? Item's 1a and 1b can
> happen
> > in
> > > > > > >> parallel,
> > > > > > >> > as could item 2 actually. There will surely be more smaller
> > > > items, but
> > > > > > >> > those are the big ones as I see it. Please chime in if I've
> > > > overlooked
> > > > > > >> > anything major.
> > > > > > >> >
> > > > > > >> > thanks,
> > > > > > >> > Bill
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > > --
> > > > > > Sent from Gmail Mobile
> > > > > >
> > > > >
> > > >
> > >
> >
>
-- 
Sent from Gmail Mobile

Re: Migrating Heron code to Apache

[Jacques Nadeau]

I'm -0 on plan.

Why not just import code then do changes 1 and 2 after 3? Just seems like
getting 3 done is a key blocking item on forward progress of the community.

On Oct 27, 2017 3:16 PM, "Sanjeev Kulkarni"  wrote:

> +1
>
> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham  wrote:
>
> > Any other comments on this proposal from Heron developers? The next
> podling
> > report is due on Wednesday so we should address our plan.
> >
> > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
> > wrote:
> >
> > > If you do in fact want to use gitbox (which allows you to have github
> > > writable repos), infra will need to be made an admin on your
> organization
> > > temporarily to do the migration.
> > >
> > > Many new projects are doing this, so it's not uncommon to just use
> gitbox
> > > since you're already on github.
> > >
> > > John
> > >
> > > On 2017-10-19 13:20, Brian Hatfield  wrote:
> > > > Thank you both for the info :-) I had not realized it would just be
> > > > re-homed in a different Github org. Thanks!
> > > >
> > > > Brian
> > > >
> > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham 
> > > wrote:
> > > >
> > > > > Right, it would still be on github, just at apache/heron instead of
> > > > > twitter/heron.
> > > > >
> > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell 
> > > wrote:
> > > > >
> > > > > > Apache git can also refer to the Github Apache org as a number of
> > > > > projects
> > > > > > are running in that fashion. They key is that the code has been
> > > imported
> > > > > > over to the Apache Infra owned/managed infrastructure
> > > > > >
> > > > > > -Jake
> > > > > >
> > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> > > bmhatfi...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Silly question - and apologies if this has already been
> discussed
> > -
> > > but
> > > > > is
> > > > > >> #3 (Migrate the code to Apache git) required? From my
> perspective
> > > Github
> > > > > >> is
> > > > > >> much more preferable as it's where nearly every other open
> source
> > > > > codebase
> > > > > >> I interact with is, and the UI is very friendly to newcomers.
> > > > > >>
> > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
> > billgra...@gmail.com
> > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > In LEGAL-339  >
> > > it was
> > > > > >> > concluded that we can in fact move the code to Apache git and
> > cut
> > > > > Apache
> > > > > >> > releases without the SGA. I propose we move forward on that. I
> > > suggest
> > > > > >> the
> > > > > >> > following plan:
> > > > > >> >
> > > > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to
> > be
> > > > > >> fetched
> > > > > >> > at build time and not committed in the repo. (#2092
> > > > > >> > )
> > > > > >> > 1.b Refactor the bazel checkstyles to support both the Twitter
> > > > > copyright
> > > > > >> > (for existing code) and the Apache copyright (for new code
> after
> > > the
> > > > > >> > migration).
> > > > > >> > 2. Cut the last non-Apache release.
> > > > > >> > 3. Migrate the code to Apache git
> > > > > >> > 4. Add incubation disclaimer
> > > > > >> > 5. Cut the first Apache release.
> > > > > >> >
> > > > > >> > What do folks think of that plan? Item's 1a and 1b can happen
> in
> > > > > >> parallel,
> > > > > >> > as could item 2 actually. There will surely be more smaller
> > > items, but
> > > > > >> > those are the big ones as I see it. Please chime in if I've
> > > overlooked
> > > > > >> > anything major.
> > > > > >> >
> > > > > >> > thanks,
> > > > > >> > Bill
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > > --
> > > > > Sent from Gmail Mobile
> > > > >
> > > >
> > >
> >
>

Re: Migrating Heron code to Apache

[Andrew Jorgensen]

Looks good to me as well!

Best,
Andrew Jorgensen
@ajorgensen

On Thu, Oct 26, 2017 at 12:21 PM, Ashvin A  wrote:

> LGTM
>
> +1
>
> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham  wrote:
>
> > Any other comments on this proposal from Heron developers? The next
> podling
> > report is due on Wednesday so we should address our plan.
> >
> > On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
> > wrote:
> >
> > > If you do in fact want to use gitbox (which allows you to have github
> > > writable repos), infra will need to be made an admin on your
> organization
> > > temporarily to do the migration.
> > >
> > > Many new projects are doing this, so it's not uncommon to just use
> gitbox
> > > since you're already on github.
> > >
> > > John
> > >
> > > On 2017-10-19 13:20, Brian Hatfield  wrote:
> > > > Thank you both for the info :-) I had not realized it would just be
> > > > re-homed in a different Github org. Thanks!
> > > >
> > > > Brian
> > > >
> > > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham 
> > > wrote:
> > > >
> > > > > Right, it would still be on github, just at apache/heron instead of
> > > > > twitter/heron.
> > > > >
> > > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell 
> > > wrote:
> > > > >
> > > > > > Apache git can also refer to the Github Apache org as a number of
> > > > > projects
> > > > > > are running in that fashion. They key is that the code has been
> > > imported
> > > > > > over to the Apache Infra owned/managed infrastructure
> > > > > >
> > > > > > -Jake
> > > > > >
> > > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> > > bmhatfi...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> Silly question - and apologies if this has already been
> discussed
> > -
> > > but
> > > > > is
> > > > > >> #3 (Migrate the code to Apache git) required? From my
> perspective
> > > Github
> > > > > >> is
> > > > > >> much more preferable as it's where nearly every other open
> source
> > > > > codebase
> > > > > >> I interact with is, and the UI is very friendly to newcomers.
> > > > > >>
> > > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
> > billgra...@gmail.com
> > > >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > In LEGAL-339  >
> > > it was
> > > > > >> > concluded that we can in fact move the code to Apache git and
> > cut
> > > > > Apache
> > > > > >> > releases without the SGA. I propose we move forward on that. I
> > > suggest
> > > > > >> the
> > > > > >> > following plan:
> > > > > >> >
> > > > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to
> > be
> > > > > >> fetched
> > > > > >> > at build time and not committed in the repo. (#2092
> > > > > >> > )
> > > > > >> > 1.b Refactor the bazel checkstyles to support both the Twitter
> > > > > copyright
> > > > > >> > (for existing code) and the Apache copyright (for new code
> after
> > > the
> > > > > >> > migration).
> > > > > >> > 2. Cut the last non-Apache release.
> > > > > >> > 3. Migrate the code to Apache git
> > > > > >> > 4. Add incubation disclaimer
> > > > > >> > 5. Cut the first Apache release.
> > > > > >> >
> > > > > >> > What do folks think of that plan? Item's 1a and 1b can happen
> in
> > > > > >> parallel,
> > > > > >> > as could item 2 actually. There will surely be more smaller
> > > items, but
> > > > > >> > those are the big ones as I see it. Please chime in if I've
> > > overlooked
> > > > > >> > anything major.
> > > > > >> >
> > > > > >> > thanks,
> > > > > >> > Bill
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > > --
> > > > > Sent from Gmail Mobile
> > > > >
> > > >
> > >
> >
>

Re: Migrating Heron code to Apache

[Ashvin A]

LGTM

+1

On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham  wrote:

> Any other comments on this proposal from Heron developers? The next podling
> report is due on Wednesday so we should address our plan.
>
> On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
> wrote:
>
> > If you do in fact want to use gitbox (which allows you to have github
> > writable repos), infra will need to be made an admin on your organization
> > temporarily to do the migration.
> >
> > Many new projects are doing this, so it's not uncommon to just use gitbox
> > since you're already on github.
> >
> > John
> >
> > On 2017-10-19 13:20, Brian Hatfield  wrote:
> > > Thank you both for the info :-) I had not realized it would just be
> > > re-homed in a different Github org. Thanks!
> > >
> > > Brian
> > >
> > > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham 
> > wrote:
> > >
> > > > Right, it would still be on github, just at apache/heron instead of
> > > > twitter/heron.
> > > >
> > > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell 
> > wrote:
> > > >
> > > > > Apache git can also refer to the Github Apache org as a number of
> > > > projects
> > > > > are running in that fashion. They key is that the code has been
> > imported
> > > > > over to the Apache Infra owned/managed infrastructure
> > > > >
> > > > > -Jake
> > > > >
> > > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> > bmhatfi...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Silly question - and apologies if this has already been discussed
> -
> > but
> > > > is
> > > > >> #3 (Migrate the code to Apache git) required? From my perspective
> > Github
> > > > >> is
> > > > >> much more preferable as it's where nearly every other open source
> > > > codebase
> > > > >> I interact with is, and the UI is very friendly to newcomers.
> > > > >>
> > > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham <
> billgra...@gmail.com
> > >
> > > > >> wrote:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > In LEGAL-339 
> > it was
> > > > >> > concluded that we can in fact move the code to Apache git and
> cut
> > > > Apache
> > > > >> > releases without the SGA. I propose we move forward on that. I
> > suggest
> > > > >> the
> > > > >> > following plan:
> > > > >> >
> > > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to
> be
> > > > >> fetched
> > > > >> > at build time and not committed in the repo. (#2092
> > > > >> > )
> > > > >> > 1.b Refactor the bazel checkstyles to support both the Twitter
> > > > copyright
> > > > >> > (for existing code) and the Apache copyright (for new code after
> > the
> > > > >> > migration).
> > > > >> > 2. Cut the last non-Apache release.
> > > > >> > 3. Migrate the code to Apache git
> > > > >> > 4. Add incubation disclaimer
> > > > >> > 5. Cut the first Apache release.
> > > > >> >
> > > > >> > What do folks think of that plan? Item's 1a and 1b can happen in
> > > > >> parallel,
> > > > >> > as could item 2 actually. There will surely be more smaller
> > items, but
> > > > >> > those are the big ones as I see it. Please chime in if I've
> > overlooked
> > > > >> > anything major.
> > > > >> >
> > > > >> > thanks,
> > > > >> > Bill
> > > > >> >
> > > > >>
> > > > >
> > > > > --
> > > > Sent from Gmail Mobile
> > > >
> > >
> >
>

Re: Migrating Heron code to Apache

[Bill Graham]

Any other comments on this proposal from Heron developers? The next podling
report is due on Wednesday so we should address our plan.

On Sat, Oct 21, 2017 at 3:38 PM, John D. Ament 
wrote:

> If you do in fact want to use gitbox (which allows you to have github
> writable repos), infra will need to be made an admin on your organization
> temporarily to do the migration.
>
> Many new projects are doing this, so it's not uncommon to just use gitbox
> since you're already on github.
>
> John
>
> On 2017-10-19 13:20, Brian Hatfield  wrote:
> > Thank you both for the info :-) I had not realized it would just be
> > re-homed in a different Github org. Thanks!
> >
> > Brian
> >
> > On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham 
> wrote:
> >
> > > Right, it would still be on github, just at apache/heron instead of
> > > twitter/heron.
> > >
> > > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell 
> wrote:
> > >
> > > > Apache git can also refer to the Github Apache org as a number of
> > > projects
> > > > are running in that fashion. They key is that the code has been
> imported
> > > > over to the Apache Infra owned/managed infrastructure
> > > >
> > > > -Jake
> > > >
> > > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield <
> bmhatfi...@gmail.com>
> > > > wrote:
> > > >
> > > >> Silly question - and apologies if this has already been discussed -
> but
> > > is
> > > >> #3 (Migrate the code to Apache git) required? From my perspective
> Github
> > > >> is
> > > >> much more preferable as it's where nearly every other open source
> > > codebase
> > > >> I interact with is, and the UI is very friendly to newcomers.
> > > >>
> > > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham  >
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > In LEGAL-339 
> it was
> > > >> > concluded that we can in fact move the code to Apache git and cut
> > > Apache
> > > >> > releases without the SGA. I propose we move forward on that. I
> suggest
> > > >> the
> > > >> > following plan:
> > > >> >
> > > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to be
> > > >> fetched
> > > >> > at build time and not committed in the repo. (#2092
> > > >> > )
> > > >> > 1.b Refactor the bazel checkstyles to support both the Twitter
> > > copyright
> > > >> > (for existing code) and the Apache copyright (for new code after
> the
> > > >> > migration).
> > > >> > 2. Cut the last non-Apache release.
> > > >> > 3. Migrate the code to Apache git
> > > >> > 4. Add incubation disclaimer
> > > >> > 5. Cut the first Apache release.
> > > >> >
> > > >> > What do folks think of that plan? Item's 1a and 1b can happen in
> > > >> parallel,
> > > >> > as could item 2 actually. There will surely be more smaller
> items, but
> > > >> > those are the big ones as I see it. Please chime in if I've
> overlooked
> > > >> > anything major.
> > > >> >
> > > >> > thanks,
> > > >> > Bill
> > > >> >
> > > >>
> > > >
> > > > --
> > > Sent from Gmail Mobile
> > >
> >
>

Re: Migrating Heron code to Apache

[John D. Ament]

If you do in fact want to use gitbox (which allows you to have github writable 
repos), infra will need to be made an admin on your organization temporarily to 
do the migration.

Many new projects are doing this, so it's not uncommon to just use gitbox since 
you're already on github.

John

On 2017-10-19 13:20, Brian Hatfield  wrote: 
> Thank you both for the info :-) I had not realized it would just be
> re-homed in a different Github org. Thanks!
> 
> Brian
> 
> On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham  wrote:
> 
> > Right, it would still be on github, just at apache/heron instead of
> > twitter/heron.
> >
> > On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell  wrote:
> >
> > > Apache git can also refer to the Github Apache org as a number of
> > projects
> > > are running in that fashion. They key is that the code has been imported
> > > over to the Apache Infra owned/managed infrastructure
> > >
> > > -Jake
> > >
> > > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield 
> > > wrote:
> > >
> > >> Silly question - and apologies if this has already been discussed - but
> > is
> > >> #3 (Migrate the code to Apache git) required? From my perspective Github
> > >> is
> > >> much more preferable as it's where nearly every other open source
> > codebase
> > >> I interact with is, and the UI is very friendly to newcomers.
> > >>
> > >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham 
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > In LEGAL-339  it was
> > >> > concluded that we can in fact move the code to Apache git and cut
> > Apache
> > >> > releases without the SGA. I propose we move forward on that. I suggest
> > >> the
> > >> > following plan:
> > >> >
> > >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to be
> > >> fetched
> > >> > at build time and not committed in the repo. (#2092
> > >> > )
> > >> > 1.b Refactor the bazel checkstyles to support both the Twitter
> > copyright
> > >> > (for existing code) and the Apache copyright (for new code after the
> > >> > migration).
> > >> > 2. Cut the last non-Apache release.
> > >> > 3. Migrate the code to Apache git
> > >> > 4. Add incubation disclaimer
> > >> > 5. Cut the first Apache release.
> > >> >
> > >> > What do folks think of that plan? Item's 1a and 1b can happen in
> > >> parallel,
> > >> > as could item 2 actually. There will surely be more smaller items, but
> > >> > those are the big ones as I see it. Please chime in if I've overlooked
> > >> > anything major.
> > >> >
> > >> > thanks,
> > >> > Bill
> > >> >
> > >>
> > >
> > > --
> > Sent from Gmail Mobile
> >
> 

Re: Migrating Heron code to Apache

[Brian Hatfield]

Thank you both for the info :-) I had not realized it would just be
re-homed in a different Github org. Thanks!

Brian

On Thu, Oct 19, 2017 at 11:58 AM, Bill Graham  wrote:

> Right, it would still be on github, just at apache/heron instead of
> twitter/heron.
>
> On Thu, Oct 19, 2017 at 8:16 AM Jake Farrell  wrote:
>
> > Apache git can also refer to the Github Apache org as a number of
> projects
> > are running in that fashion. They key is that the code has been imported
> > over to the Apache Infra owned/managed infrastructure
> >
> > -Jake
> >
> > On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield 
> > wrote:
> >
> >> Silly question - and apologies if this has already been discussed - but
> is
> >> #3 (Migrate the code to Apache git) required? From my perspective Github
> >> is
> >> much more preferable as it's where nearly every other open source
> codebase
> >> I interact with is, and the UI is very friendly to newcomers.
> >>
> >> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > In LEGAL-339  it was
> >> > concluded that we can in fact move the code to Apache git and cut
> Apache
> >> > releases without the SGA. I propose we move forward on that. I suggest
> >> the
> >> > following plan:
> >> >
> >> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to be
> >> fetched
> >> > at build time and not committed in the repo. (#2092
> >> > )
> >> > 1.b Refactor the bazel checkstyles to support both the Twitter
> copyright
> >> > (for existing code) and the Apache copyright (for new code after the
> >> > migration).
> >> > 2. Cut the last non-Apache release.
> >> > 3. Migrate the code to Apache git
> >> > 4. Add incubation disclaimer
> >> > 5. Cut the first Apache release.
> >> >
> >> > What do folks think of that plan? Item's 1a and 1b can happen in
> >> parallel,
> >> > as could item 2 actually. There will surely be more smaller items, but
> >> > those are the big ones as I see it. Please chime in if I've overlooked
> >> > anything major.
> >> >
> >> > thanks,
> >> > Bill
> >> >
> >>
> >
> > --
> Sent from Gmail Mobile
>

Re: Migrating Heron code to Apache

[Jake Farrell]

Apache git can also refer to the Github Apache org as a number of projects
are running in that fashion. They key is that the code has been imported
over to the Apache Infra owned/managed infrastructure

-Jake

On Thu, Oct 19, 2017 at 11:04 AM, Brian Hatfield 
wrote:

> Silly question - and apologies if this has already been discussed - but is
> #3 (Migrate the code to Apache git) required? From my perspective Github is
> much more preferable as it's where nearly every other open source codebase
> I interact with is, and the UI is very friendly to newcomers.
>
> On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham 
> wrote:
>
> > Hi,
> >
> > In LEGAL-339  it was
> > concluded that we can in fact move the code to Apache git and cut Apache
> > releases without the SGA. I propose we move forward on that. I suggest
> the
> > following plan:
> >
> > 1.a Refactor all Heron build dependencies (mainly c++ libs) to be fetched
> > at build time and not committed in the repo. (#2092
> > )
> > 1.b Refactor the bazel checkstyles to support both the Twitter copyright
> > (for existing code) and the Apache copyright (for new code after the
> > migration).
> > 2. Cut the last non-Apache release.
> > 3. Migrate the code to Apache git
> > 4. Add incubation disclaimer
> > 5. Cut the first Apache release.
> >
> > What do folks think of that plan? Item's 1a and 1b can happen in
> parallel,
> > as could item 2 actually. There will surely be more smaller items, but
> > those are the big ones as I see it. Please chime in if I've overlooked
> > anything major.
> >
> > thanks,
> > Bill
> >
>

Re: Migrating Heron code to Apache

[Jake Farrell]

+1 sounds good. Based on the discussion in LEGAL-339, we will need to get
the SGA submitted prior to graduating from the incubator and becoming a top
level project, but we can track that progress as a jira story and not block
incubator and day to day code development

-Jake

On Thu, Oct 19, 2017 at 11:01 AM, Bill Graham  wrote:

> Hi,
>
> In LEGAL-339  it was
> concluded that we can in fact move the code to Apache git and cut Apache
> releases without the SGA. I propose we move forward on that. I suggest the
> following plan:
>
> 1.a Refactor all Heron build dependencies (mainly c++ libs) to be fetched
> at build time and not committed in the repo. (#2092
> )
> 1.b Refactor the bazel checkstyles to support both the Twitter copyright
> (for existing code) and the Apache copyright (for new code after the
> migration).
> 2. Cut the last non-Apache release.
> 3. Migrate the code to Apache git
> 4. Add incubation disclaimer
> 5. Cut the first Apache release.
>
> What do folks think of that plan? Item's 1a and 1b can happen in parallel,
> as could item 2 actually. There will surely be more smaller items, but
> those are the big ones as I see it. Please chime in if I've overlooked
> anything major.
>
> thanks,
> Bill
>

Migrating Heron code to Apache

[Bill Graham]

Hi,

In LEGAL-339  it was
concluded that we can in fact move the code to Apache git and cut Apache
releases without the SGA. I propose we move forward on that. I suggest the
following plan:

1.a Refactor all Heron build dependencies (mainly c++ libs) to be fetched
at build time and not committed in the repo. (#2092
)
1.b Refactor the bazel checkstyles to support both the Twitter copyright
(for existing code) and the Apache copyright (for new code after the
migration).
2. Cut the last non-Apache release.
3. Migrate the code to Apache git
4. Add incubation disclaimer
5. Cut the first Apache release.

What do folks think of that plan? Item's 1a and 1b can happen in parallel,
as could item 2 actually. There will surely be more smaller items, but
those are the big ones as I see it. Please chime in if I've overlooked
anything major.

thanks,
Bill