incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Tue, 28 Feb 2012 14:01:28 GMT
On 02/28/2012 01:46 PM, Mohammad Nour El-Din wrote:
> Hi...
>     1st of all, and I speaking about myself here, I believe this is
> partially my fault cause I am one of the mentors of Sqoop and I should have
> spotted such thing before moving the vote to general@
> I totally agree with Alex, more specifically I believe this is easy to
> solve.
> There is no problem to support some features or API(s)
> for backward compatibility but as Alex stated it should not be part of
> Apache's code, more specifically when it comes to be part of a TLP's code.

I agree.

And specifically as this seems to concern compatibility support for Cloudera own 
API, only needed for Cloudera customers.
Keeping those com.cloudera packages in the code could imply a specific 
preference and affiliation with an external and commercial entity, thereby 
potentially jeopardizing the project independence.

While I don't expect there was any intend to do so, even the impression itself 
can be considered harmful to the ASF and the project.

> The solution can be like packaging this code and host it on Cloudera or
> even Apache Extras [1] and a note is added to Sqoop website that if users
> want to have backward compatibility they should use that code besides the
> code of Apache.

That sounds reasonable and hopefully easy to do (if not this case might even be 
more worrisome then).
I'm not really sure though if Apache Extras is an appropriate location either. I 
think Apache Extras intends to convey an affiliation with the ASF and probably 
should value project independence high as well.
If this really only concerns a thin layer to provide compatibility only for 
Cloudera's API, hosting and maintenance of this should be the responsibility of 
Cloudera itself.


> Now the question is, and I ask this more specifically to the Sqoop people,
> Can you do this before the next board meeting, at least the extracting that
> code ? Cause if not I support Alex in that this vote should be cancelled
> and then we work out another one when Sqoop meets this criteria.
> Looking forward to your feedback!
> [1] -
> On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasulu<>wrote:
>> On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting<
>>> wrote:
>>> Hi,
>>> On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu<>
>>> wrote:
>>>> Cloudera's compatibility issues are not our problem. These packages
>> need
>>> to
>>>> go.
>>> Citation needed.
>> I did not think we needed one: nor do I have one. It's common sense to me
>> that this causes issues. It combines the namespace of a foreign mark with
>> our own. We should not be releasing anything in the namespace belonging to
>> another entity.
>>> Without a written policy to that effect these things
>>> are up for each project to decide. Jarek's rationale sounds perfectly
>>> fine to me.
>> I highly respect you opinion here but I disagree regarding this argument
>> provided. There may be no policy to cite, and there may be examples of
>> where this was done before for the sake of backwards compatibility. It
>> still does not justify doing it.
>>> We have plenty of projects that provide such backwards compatibility
>>> wrappers or otherwise put stuff in non-apache namespaces for various
>>> reasons. See for example [1] or [2].
>> Understood. Examples are solid points supporting the argument but IMHO I
>> think this was a mistake that opens the door to several issues. Maybe we
>> need some clear policy regarding the matter. I'm more than ready to be
>> proven wrong on this matter so long as it does not present problems down
>> the line for us.
>>> [1]
>>> [2]
>>> BR,
>>> Jukka Zitting
>> --
>> Best Regards,
>> -- Alex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message