incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Tue, 28 Feb 2012 19:37:23 GMT

On Feb 28, 2012, at 11:29 AM, Arvind Prabhakar wrote:

> On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera <> wrote:
>> On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:
>>> On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera <>
>>>> On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
>>>>> On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera <>
>>>>>> On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
>>>>>>> On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting <>
>>>>>>>> On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu <>
>>>>>> I'm not sure that JSR specs are the same as old Cloudera code.  JMHO.
>>>>> How about phrasing it as "old Sqoop code" instead. :-)
>>>>> Really it's about respect for existing users and others migrating to
>>>>> Apache. It's also about respect for the people doing the work. That's
>>>>> my understanding from discussions with the team at least.
>>>>>> I don't see the technical requirement that this code needs to stay
at Apache and not Cloudera.
>>>>> I agree that this potentially could be an issue, but whether it's a
>>>>> technical requirement is up to the team who's doing the work. If
>>>>> Apache feels that there is a requirement that no project releases
>>>>> code/document/etc... under any package other than org.apache.* then
>>>>> that should be clearly defined and communicated. At this point my
>>>>> understanding is there is no such requirement.
>>>> public class MySQLManager
>>>>    extends org.apache.sqoop.manager.MySQLManager {
>>>>  public MySQLManager(final SqoopOptions opts) {
>>>>    super(opts);
>>>>  }
>>>> }
>>>> If all the code is like this it is absolutely ridiculous to have this at
Apache and not Cloudera.
>>> Please see [1] for details on why the code is like this. The short
>>> summary is that binary compatibility requires us to respect all
>>> extension points within the code.
>>> [1]
>> IIUC, this document merely outlines how the move should be performed.  This has been
completed and what's left are bindings for those who wish to use the old bindings from the
old project.  There's no technical reason why those bindings for the old project must be housed
here at Apache.
> You are right that it outlines how the move should be performed. Along
> with that it also describes the motivation and specific technical
> requirements to be fulfilled. Following are the relevant quotes from
> the document:
> [From Overview - Motivation]
> Considering that there is a lot of third party code that is developed
> on top of/to work with Sqoop, this migration is particularly risky for
> backward compatibility and thus requires careful handling. This
> document outlines the steps that seem reasonable for such migration.
> [From Migration-General Approach - Technical Requirement]
> When migrating a class from its previous namespace to the new, the key
> requirement to address is that any code written to the old class
> should still work at binary compatibility level. This also implies
> that such code should be able to recompile with the migrated code base
> without any modifications. In order to enable this, the general
> approach is as follows:
> * Any old public/protected/default access level API should be
> preserved as is, but marked deprecated.
> * Any logic that exists in this API should be migrated to the new namespace.
> Note that API is not just method signatures but includes all aspects
> of implementation such as class hierarchies, type compatibility,
> static and non-static state etc.

I think that it's good to have binary compatibility with Cloudera's old bindings.   I still
don't see why it's a requirement for Apache to house code whose sole use is to provide backward
compatible bindings for Cloudera's old bindings.


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