incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Nour El-Din <nour.moham...@gmail.com>
Subject Re: [VOTE] Graduate Sqoop podling from Apache Incubator
Date Tue, 28 Feb 2012 14:09:17 GMT
On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma <ate@douma.nu> wrote:

> 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.


Good point, I agree on this


>
>
> Ate
>
>
>
>> 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] - http://code.google.com/a/**apache-extras.org/hosting/<http://code.google.com/a/apache-extras.org/hosting/>
>>
>> On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasulu<akarasulu@apache.org>**
>> wrote:
>>
>>  On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting<jukka.zitting@gmail.**
>>> com <jukka.zitting@gmail.com>
>>>
>>>> wrote:
>>>>
>>>
>>>  Hi,
>>>>
>>>> On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu<akarasulu@apache.org>
>>>> 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]
>>>>
>>>>  http://svn.apache.org/repos/**asf/subversion/trunk/**
>>> subversion/bindings/javahl/<http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/>
>>>
>>>> [2] http://svn.apache.org/repos/**asf/geronimo/specs/trunk/<http://svn.apache.org/repos/asf/geronimo/specs/trunk/>
>>>>
>>>> BR,
>>>>
>>>> Jukka Zitting
>>>>
>>>>
>>>>  --
>>> Best Regards,
>>> -- Alex
>>>
>>>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<general-unsubscribe@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<general-help@incubator.apache.org>
>
>


-- 
Thanks
- Mohammad Nour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

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