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.
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/
On Tue, Feb 28, 2012 at 10:44 AM, Alex Karasulu<akaras...@apache.org>wrote:
On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting<jukka.zitt...@gmail.com
wrote:
Hi,
On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu<akaras...@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/
[2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/
BR,
Jukka Zitting
--
Best Regards,
-- Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
