heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "P. Taylor Goetz" <ptgo...@gmail.com>
Subject Re: Migrating Heron code to Apache
Date Wed, 08 Nov 2017 18:47:24 GMT
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 <julien.ledem@gmail.com> 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 <jacques@apache.org> 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 <billgraham@gmail.com> 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 <jacques@apache.org>
>> 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" <sanjeevrk@gmail.com>
>> wrote:
>>>> 
>>>>> +1
>>>>> 
>>>>> On Thu, Oct 26, 2017 at 9:15 AM, Bill Graham <billgraham@gmail.com>
>>>> 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 <
>>> johndament@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 <bmhatfield@gmail.com>
>> 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 <
>>>> billgraham@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 <
>>>> jfarrell@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
<
>>>>>>> bmhatfield@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
<
>>>>>> billgraham@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
>>>>>>>>>>>> <https://github.com/twitter/heron/issues/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
>>> 
>> 


Mime
View raw message