date:20120228

On Tue, Feb 28, 2012 at 10:33 AM, Ate Douma a...@douma.nu wrote:

 +1 (binding)


+1 (binding)

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote:

 The source code in Sqoop still exists in both com.cloudera.sqoop and
 org.apache.sqoop packages and most of the code appears to include the
 com.cloudera packages and not the org.apache packages.  While in the
 incubator this seems fine.  Are we ok with this in a TLP?  I couldn't find
 any policy statements on it in the Apache pages.


Good catch Alan. You are right we are not OK with this situation. It needs
to be corrected then another vote can be taken.

Thanks,
Alex



 On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote:

  This is a call for vote to graduate Sqoop podling from Apache Incubator.
 
  Sqoop entered Incubator in June of 2011. Since then it has added three
  new committers from diverse organizations, added two new PPMC members,
  and made two releases following the ASF policies and guidelines. The
  community of Sqoop is active, healthy and growing and has demonstrated
  the ability to self-govern using accepted Apache practices. Sqoop
  community has voted to proceed with graduation [1] and the result can
  be found at [2].
 
  Please cast your votes:
 
  [  ] +1 Graduate Sqoop podling from Apache Incubator
  [  ] +0 Indifferent to the graduation status of Sqoop podling
  [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
 
  This vote will be open for 72 hours. Please find the proposed board
  resolution below.
 
  [1] http://markmail.org/thread/xwhjtkik7pgrmypi
  [2] http://s.apache.org/sqoop
 
  Thanks,
  Arvind Prabhakar
 
  X. Establish the Apache Sqoop Project
 
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to efficiently transferring
bulk data between Apache Hadoop and structured datastores
for distribution at no charge to the public.
 
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Sqoop Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
 
RESOLVED, that the Apache Sqoop Project be and hereby is
responsible for the creation and maintenance of software
related to efficiently transferring bulk data between Apache
Hadoop and structured datastores; and be it further
 
RESOLVED, that the office of Vice President, Apache Sqoop be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Sqoop Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Sqoop Project; and be it further
 
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Sqoop Project:
 
  * Aaron Kimball kimba...@apache.org
  * Andrew Bayer  aba...@apache.org
  * Ahmed Radwan  ah...@apache.org
  * Arvind Prabhakar  arv...@apache.org
  * Bilung Leeb...@apache.org
  * Greg Cottman  gcott...@apache.org
  * Guy le Marguyle...@apache.org
  * Jaroslav Cechojar...@apache.org
  * Jonathan Hsiehjmhs...@apache.org
  * Olivier Lamy  ol...@apache.org
  * Paul Zimdars  pzimd...@apache.org
  * Roman Shaposhnik  r...@apache.org
 
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
be appointed to the office of Vice President, Apache Sqoop, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
 
RESOLVED, that the initial Apache Sqoop PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Sqoop Project; and be it further
 
RESOLVED, that the Apache Sqoop Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Sqoop podling; and be it further
 
RESOLVED, that all responsibilities pertaining to the Apache
Incubator Sqoop podling encumbered upon the Apache Incubator
Project are hereafter discharged.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail:

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

Alex, Alan,

Thanks for your feedback. Please take a look at SQOOP-369:

https://issues.apache.org/jira/browse/SQOOP-369

All of the source code for Sqoop that exists in com.cloudera namespace
is deprecated and the actual implementation of the product has been
moved under org.apache namespace.

The only reason com.cloudera namespace exists is in order to provide
backward compatibility with third party code.

Thanks,
Arvind Prabhakar




On Tue, Feb 28, 2012 at 12:39 AM, Alex Karasulu akaras...@apache.org wrote:
 On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote:

 The source code in Sqoop still exists in both com.cloudera.sqoop and
 org.apache.sqoop packages and most of the code appears to include the
 com.cloudera packages and not the org.apache packages.  While in the
 incubator this seems fine.  Are we ok with this in a TLP?  I couldn't find
 any policy statements on it in the Apache pages.


 Good catch Alan. You are right we are not OK with this situation. It needs
 to be corrected then another vote can be taken.

 Thanks,
 Alex



 On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote:

  This is a call for vote to graduate Sqoop podling from Apache Incubator.
 
  Sqoop entered Incubator in June of 2011. Since then it has added three
  new committers from diverse organizations, added two new PPMC members,
  and made two releases following the ASF policies and guidelines. The
  community of Sqoop is active, healthy and growing and has demonstrated
  the ability to self-govern using accepted Apache practices. Sqoop
  community has voted to proceed with graduation [1] and the result can
  be found at [2].
 
  Please cast your votes:
 
  [  ] +1 Graduate Sqoop podling from Apache Incubator
  [  ] +0 Indifferent to the graduation status of Sqoop podling
  [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
 
  This vote will be open for 72 hours. Please find the proposed board
  resolution below.
 
  [1] http://markmail.org/thread/xwhjtkik7pgrmypi
  [2] http://s.apache.org/sqoop
 
  Thanks,
  Arvind Prabhakar
 
  X. Establish the Apache Sqoop Project
 
        WHEREAS, the Board of Directors deems it to be in the best
        interests of the Foundation and consistent with the
        Foundation's purpose to establish a Project Management
        Committee charged with the creation and maintenance of
        open-source software related to efficiently transferring
        bulk data between Apache Hadoop and structured datastores
        for distribution at no charge to the public.
 
        NOW, THEREFORE, BE IT RESOLVED, that a Project Management
        Committee (PMC), to be known as the Apache Sqoop Project,
        be and hereby is established pursuant to Bylaws of the
        Foundation; and be it further
 
        RESOLVED, that the Apache Sqoop Project be and hereby is
        responsible for the creation and maintenance of software
        related to efficiently transferring bulk data between Apache
        Hadoop and structured datastores; and be it further
 
        RESOLVED, that the office of Vice President, Apache Sqoop be
        and hereby is created, the person holding such office to
        serve at the direction of the Board of Directors as the chair
        of the Apache Sqoop Project, and to have primary responsibility
        for management of the projects within the scope of
        responsibility of the Apache Sqoop Project; and be it further
 
        RESOLVED, that the persons listed immediately below be and
        hereby are appointed to serve as the initial members of the
        Apache Sqoop Project:
 
          * Aaron Kimball             kimba...@apache.org
          * Andrew Bayer              aba...@apache.org
          * Ahmed Radwan              ah...@apache.org
          * Arvind Prabhakar          arv...@apache.org
          * Bilung Lee                b...@apache.org
          * Greg Cottman              gcott...@apache.org
          * Guy le Mar                guyle...@apache.org
          * Jaroslav Cecho            jar...@apache.org
          * Jonathan Hsieh            jmhs...@apache.org
          * Olivier Lamy              ol...@apache.org
          * Paul Zimdars              pzimd...@apache.org
          * Roman Shaposhnik          r...@apache.org
 
        NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
        be appointed to the office of Vice President, Apache Sqoop, to
        serve in accordance with and subject to the direction of the
        Board of Directors and the Bylaws of the Foundation until
        death, resignation, retirement, removal or disqualification,
        or until a successor is appointed; and be it further
 
        RESOLVED, that the initial Apache Sqoop PMC be and hereby is
        tasked with the creation of a set of bylaws intended to
        encourage open development and increased participation in the
        Apache Sqoop Project; and be it further
 
        RESOLVED, that the

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Jarek Jarcec Cecho

Hi Alex and Alan,
we already moved entire logic to org.apache namespace. We're keeping classes in 
com.cloudera in place only for compatibility with tools that are based on sqoop 
(for example various connectors). However those classes do not contain any 
logic, they are just inheriting from org.apache namespace and do nothing. Let 
me show you what I mean on following example:

https://svn.apache.org/repos/asf/incubator/sqoop/trunk/src/java/com/cloudera/sqoop/manager/MySQLManager.java

All other files in com.cloudera namespace have similar structure. They are just 
skeleton code that is in place for compatibility without any logic (additional 
code).

Do we really need to remove entirely com.cloudera namespace or is this state 
acceptable for graduating?

Jarcec

On Tue, Feb 28, 2012 at 10:39:35AM +0200, Alex Karasulu wrote:
 On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote:
 
  The source code in Sqoop still exists in both com.cloudera.sqoop and
  org.apache.sqoop packages and most of the code appears to include the
  com.cloudera packages and not the org.apache packages.  While in the
  incubator this seems fine.  Are we ok with this in a TLP?  I couldn't find
  any policy statements on it in the Apache pages.
 
 
 Good catch Alan. You are right we are not OK with this situation. It needs
 to be corrected then another vote can be taken.
 
 Thanks,
 Alex
 
 
 
  On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote:
 
   This is a call for vote to graduate Sqoop podling from Apache Incubator.
  
   Sqoop entered Incubator in June of 2011. Since then it has added three
   new committers from diverse organizations, added two new PPMC members,
   and made two releases following the ASF policies and guidelines. The
   community of Sqoop is active, healthy and growing and has demonstrated
   the ability to self-govern using accepted Apache practices. Sqoop
   community has voted to proceed with graduation [1] and the result can
   be found at [2].
  
   Please cast your votes:
  
   [  ] +1 Graduate Sqoop podling from Apache Incubator
   [  ] +0 Indifferent to the graduation status of Sqoop podling
   [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
  
   This vote will be open for 72 hours. Please find the proposed board
   resolution below.
  
   [1] http://markmail.org/thread/xwhjtkik7pgrmypi
   [2] http://s.apache.org/sqoop
  
   Thanks,
   Arvind Prabhakar
  
   X. Establish the Apache Sqoop Project
  
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the
 Foundation's purpose to establish a Project Management
 Committee charged with the creation and maintenance of
 open-source software related to efficiently transferring
 bulk data between Apache Hadoop and structured datastores
 for distribution at no charge to the public.
  
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Sqoop Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further
  
 RESOLVED, that the Apache Sqoop Project be and hereby is
 responsible for the creation and maintenance of software
 related to efficiently transferring bulk data between Apache
 Hadoop and structured datastores; and be it further
  
 RESOLVED, that the office of Vice President, Apache Sqoop be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache Sqoop Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Sqoop Project; and be it further
  
 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Sqoop Project:
  
   * Aaron Kimball kimba...@apache.org
   * Andrew Bayer  aba...@apache.org
   * Ahmed Radwan  ah...@apache.org
   * Arvind Prabhakar  arv...@apache.org
   * Bilung Leeb...@apache.org
   * Greg Cottman  gcott...@apache.org
   * Guy le Marguyle...@apache.org
   * Jaroslav Cechojar...@apache.org
   * Jonathan Hsiehjmhs...@apache.org
   * Olivier Lamy  ol...@apache.org
   * Paul Zimdars  pzimd...@apache.org
   * Roman Shaposhnik  r...@apache.org
  
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
 be appointed to the office of Vice President, Apache Sqoop, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until

Re: [VOTE] Graduate Apache Rave as TLP

2012-02-28 Thread Jukka Zitting

Hi,

On Mon, Feb 27, 2012 at 1:26 PM, Ate Douma a...@douma.nu wrote:
 I therefore now request the IPMC to vote on recommending the graduation of
 Rave with the below resolution [2] to the ASF Board.

   [x] +1 to recommend graduation of Apache Rave as TLP

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Jukka Zitting

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. Without a written policy to that effect these things
are up for each project to decide. Jarek's rationale sounds perfectly
fine to me.

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

[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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

Good catch

On Mon, Feb 27, 2012 at 9:10 PM, Alan Gates ga...@hortonworks.com wrote:

 The source code in Sqoop still exists in both com.cloudera.sqoop and
 org.apache.sqoop packages and most of the code appears to include the
 com.cloudera packages and not the org.apache packages.  While in the
 incubator this seems fine.  Are we ok with this in a TLP?  I couldn't find
 any policy statements on it in the Apache pages.


No this is not OK with a TLP



 Alan.


 On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote:

  This is a call for vote to graduate Sqoop podling from Apache Incubator.
 
  Sqoop entered Incubator in June of 2011. Since then it has added three
  new committers from diverse organizations, added two new PPMC members,
  and made two releases following the ASF policies and guidelines. The
  community of Sqoop is active, healthy and growing and has demonstrated
  the ability to self-govern using accepted Apache practices. Sqoop
  community has voted to proceed with graduation [1] and the result can
  be found at [2].
 
  Please cast your votes:
 
  [  ] +1 Graduate Sqoop podling from Apache Incubator
  [  ] +0 Indifferent to the graduation status of Sqoop podling
  [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
 
  This vote will be open for 72 hours. Please find the proposed board
  resolution below.
 
  [1] http://markmail.org/thread/xwhjtkik7pgrmypi
  [2] http://s.apache.org/sqoop
 
  Thanks,
  Arvind Prabhakar
 
  X. Establish the Apache Sqoop Project
 
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to efficiently transferring
bulk data between Apache Hadoop and structured datastores
for distribution at no charge to the public.
 
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Sqoop Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
 
RESOLVED, that the Apache Sqoop Project be and hereby is
responsible for the creation and maintenance of software
related to efficiently transferring bulk data between Apache
Hadoop and structured datastores; and be it further
 
RESOLVED, that the office of Vice President, Apache Sqoop be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Sqoop Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Sqoop Project; and be it further
 
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Sqoop Project:
 
  * Aaron Kimball kimba...@apache.org
  * Andrew Bayer  aba...@apache.org
  * Ahmed Radwan  ah...@apache.org
  * Arvind Prabhakar  arv...@apache.org
  * Bilung Leeb...@apache.org
  * Greg Cottman  gcott...@apache.org
  * Guy le Marguyle...@apache.org
  * Jaroslav Cechojar...@apache.org
  * Jonathan Hsiehjmhs...@apache.org
  * Olivier Lamy  ol...@apache.org
  * Paul Zimdars  pzimd...@apache.org
  * Roman Shaposhnik  r...@apache.org
 
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
be appointed to the office of Vice President, Apache Sqoop, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
 
RESOLVED, that the initial Apache Sqoop PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Sqoop Project; and be it further
 
RESOLVED, that the Apache Sqoop Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Sqoop podling; and be it further
 
RESOLVED, that all responsibilities pertaining to the Apache
Incubator Sqoop podling encumbered upon the Apache Incubator
Project are hereafter discharged.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

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.

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.

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

 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




-- 
Thanks
- Mohammad Nour

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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Ate Douma


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 Karasuluakaras...@apache.orgwrote:


On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitt...@gmail.com

wrote:



Hi,

On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma a...@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 Karasuluakaras...@apache.org**
wrote:

On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitting@gmail.**
com jukka.zitt...@gmail.com

wrote:

Hi,

On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@apache.org
wrote:

Cloudera's compatibility issues are not our problem. These packages

need

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.orggeneral-unsubscr...@incubator.apache.org
For additional commands, e-mail:
general-help@incubator.apache.**orggeneral-h...@incubator.apache.org

--
Thanks
- Mohammad Nour

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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 4:09 PM, Mohammad Nour El-Din 
nour.moham...@gmail.com wrote:

 On Tue, Feb 28, 2012 at 3:01 PM, Ate Douma a...@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


+1



 
 
  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 Karasuluakaras...@apache.org**
  wrote:
 
   On Tue, Feb 28, 2012 at 11:06 AM, Jukka Zittingjukka.zitting@gmail.**
  com jukka.zitt...@gmail.com
 
  wrote:
 
 
   Hi,
 
  On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasuluakaras...@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-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-help@incubator.apache.**org
 general-h...@incubator.apache.org
 
 


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




-- 
Best Regards,
-- Alex

[jira] [Commented] (PODLINGNAMESEARCH-3) Establish whether Apache Accumulo is a suitable name

2012-02-28 Thread Billie Rinaldi (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218236#comment-13218236
 ] 

Billie Rinaldi commented on PODLINGNAMESEARCH-3:


After discussing the results of this search with trademarks@, the PPMC has 
decided that Apache Accumulo is a suitable name.

 Establish whether Apache Accumulo is a suitable name
 --

 Key: PODLINGNAMESEARCH-3
 URL: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-3
 Project: Podling Suitable Names Search
  Issue Type: Suitable Name Search
Reporter: Alan Cabrera



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 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. Without a written policy to that effect these things
 are up for each project to decide. Jarek's rationale sounds perfectly
 fine to me.

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

 [1] 
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/
 [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/


I agree with Jukka on this. There is no such policy. There are
examples of well established TLPs doing similar. The files are
explicitly deprecated and will be eventually removed, they are for the
convenience of users and others building on top of Sqoop who are
migrating from the original code base to Apache based packages. It
makes total sense to provide a bridge that enables that group to move
to the Apache version of the code.

Patrick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator


On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 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. Without a written policy to that effect these things
 are up for each project to decide. Jarek's rationale sounds perfectly
 fine to me.
 
 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].
 
 [1] 
 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/
 [2] http://svn.apache.org/repos/asf/geronimo/specs/trunk/
 
 
 I agree with Jukka on this. There is no such policy. There are
 examples of well established TLPs doing similar. The files are
 explicitly deprecated and will be eventually removed, they are for the
 convenience of users and others building on top of Sqoop who are
 migrating from the original code base to Apache based packages. It
 makes total sense to provide a bridge that enables that group to move
 to the Apache version of the code.

I'm not sure that JSR specs are the same as old Cloudera code.  JMHO.

As for the Tigris/Subversion code I am surprised that they allowed it.  I am 
surprised that the Foundation would allow the Subversion project to allow it.

Normally I would be in the same boat as Jukka and Patrick in curbing the usual 
ad hoc requirements that IPMC members seem to tack on to votes but I think that 
this problem is quite a different animal, in my opinion.   I don't see the 
technical requirement that this code needs to stay at Apache and not Cloudera.


Regards,
Alan

 
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org wrote:
 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.

Patrick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com
 wrote:
  On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
  On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org
 wrote:
  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.


The Incubator is a work in progress, just like anything else here. I think
this is a policy we should adhere too from this point forward. The
technical problem is small in comparison to other issues this brings into
play.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 10:20 AM, Alex Karasulu akaras...@apache.org wrote:
 On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote:
 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.


 I think this is a policy we should adhere too from this point forward.

Apache wide policy or incubator policy? If it's not Apache wide then
any project could just wait till graduation and do as they see fit.
The idea of incubation is to ensure that a podling adheres to Apache
policy before being let loose to run itself. If we make this an
incubator only restriction we're saying that that's not the case.

 The technical problem is small in comparison to other issues this brings into 
 play.

What issues? That people will be confused about whether Apache
released/branded code, downloaded from Apache, where the majority of
the code is org.apache packaged, but some subset of clearly marked
deprecated code, defined as an aid for migration is Apache or not?
Doesn't seem like an issue to me.

Patrick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 8:34 PM, Patrick Hunt ph...@apache.org wrote:

 On Tue, Feb 28, 2012 at 10:20 AM, Alex Karasulu akaras...@apache.org
 wrote:
  On Tue, Feb 28, 2012 at 8:13 PM, Patrick Hunt ph...@apache.org wrote:
  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.
 
 
  I think this is a policy we should adhere too from this point forward.

 Apache wide policy or incubator policy? If it's not Apache wide then
 any project could just wait till graduation and do as they see fit.
 The idea of incubation is to ensure that a podling adheres to Apache
 policy before being let loose to run itself. If we make this an
 incubator only restriction we're saying that that's not the case.


That's a good point.


  The technical problem is small in comparison to other issues this brings
 into play.

 What issues? That people will be confused about whether Apache
 released/branded code, downloaded from Apache, where the majority of
 the code is org.apache packaged, but some subset of clearly marked
 deprecated code, defined as an aid for migration is Apache or not?
 Doesn't seem like an issue to me.


I think the issues were amply expressed in this thread. Just take a look at
what Ate, Mo, and I said earlier.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator


On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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.  


Regards,
Alan

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration



 Regards,
 Alan



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Doug Cutting

On 02/28/2012 12:59 AM, Alex Karasulu wrote:
 That namespace is a mark of Cloudera. 

Package names are not generally considered to be trademarks.

Doug

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Doug Cutting

On 02/28/2012 06:01 AM, Ate Douma wrote:
 And specifically as this seems to concern compatibility support for
 Cloudera own API, only needed for Cloudera customers.

Sqoop was an Apache-licensed open source project at Github before it
came to Apache.  It's thus safe to assume that it had users who were not
Cloudera customers before it came to Apache.

Doug




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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.

This is a code issue, which is up the the team
(committers/pmc/community) doing the work. If they want to include
such code it's up to them. They are doing the work.

What's really at issue here is whether all (java) code at Apache MUST
be under org.apache.* package structure or not. afaik there is
currently no such requirement. If Apache decides to make it a
requirement then great, I'm sure the Sqoop team will make the
necessary changes.


We should also give Arvind and the rest of the Sqoop community some
indication how to proceed, given the voting period is completed.

Patrick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator


On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:

 On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 
 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
 
 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration

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.


Regards,
Alan

 
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:

 On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:

 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration

 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.

Thanks,
Arvind Prabhakar



 Regards,
 Alan


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator


On Feb 28, 2012, at 10:56 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 
 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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.
 
 This is a code issue, which is up the the team
 (committers/pmc/community) doing the work. If they want to include
 such code it's up to them. They are doing the work.
 
 What's really at issue here is whether all (java) code at Apache MUST
 be under org.apache.* package structure or not. afaik there is
 currently no such requirement. If Apache decides to make it a
 requirement then great, I'm sure the Sqoop team will make the
 necessary changes.

Part of Incubation has always been the migration to the org.apache.* package 
space.   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.

 We should also give Arvind and the rest of the Sqoop community some
 indication how to proceed, given the voting period is completed.

A concern has been raised by IPMC members and an effort is being made to garner 
consensus.  The voting period is on hold.


Regards,
Alan

Re: [VOTE] Graduate Sqoop podling from Apache Incubator


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

 On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 
 On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:
 
 On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 
 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:
 
 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting 
 jukka.zitt...@gmail.com wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 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] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration
 
 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.


Regards,
Alan

Re: [VOTE] Graduate Apache Rave as TLP

+1 - binding


Regards,
Alan

 
On Feb 27, 2012, at 4:26 AM, Ate Douma wrote:

 Hi IPMCers and Incubator community,
 
 Apache Rave entered the Incubator almost 1 year ago on March 1st 2011.
 Since then Rave provided 7 incubator releases, added 3 more committers/PPMC 
 members, and shows a steady growth of community and interest in general.
 Diversity is great, as is the collaboration between the project members and 
 with the community as a whole.
 
 The Rave PPMC decided it is now time to consider graduation from the 
 Incubator and held a community vote which was accepted unanimous and includes 
 the support of the 4 Rave Mentors [1].
 
 I therefore now request the IPMC to vote on recommending the graduation of 
 Rave with the below resolution [2] to the ASF Board.
 
 Please cast your votes:
 
 [ ] +1 to recommend graduation of Apache Rave as TLP
 [ ] +0 don't care.
 [ ] -1 no, don't recommend yet, because ...
 
 This vote will be open for 72 hours.
 
 Regards, Ate
 
 [1] http://s.apache.org/TBH
 
 [2] https://issues.apache.org/jira/browse/RAVE-428, and copied below:
 
 X. Establish the Apache Rave Project
 
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to a widgets-based, web-and-social
mashup platform for distribution at no charge to the public.
 
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Rave Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
 
RESOLVED, that the Apache Rave Project be and hereby is
responsible for the creation and maintenance of software
related to a widgets-based, web-and-social mashup platform;
and be it further
 
RESOLVED, that the office of Vice President, Apache Rave be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Rave Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Rave Project; and be it further
 
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Rave Project:
 
* Ard Schrijvers  a...@apache.org
* Ate Douma   a...@apache.org
* Bas Zoetekouw   b...@apache.org
* Gerald Guo  zh...@apache.org
* Hadrian Zbarcea hadr...@apache.org
* Jasha Joachimsthal  ja...@apache.org
* Jesse Ciancetta jc...@apache.org
* Joost van Dijk  joostvand...@apache.org
* Maarten Kremers mkrem...@apache.org
* Marlon Pierce   mpie...@apache.org
* Matt Franklin   mfrank...@apache.org
* Niels van Dijk  cthi...@apache.org
* Okke Harsta ohar...@apache.org
* Raminder Singh  ramin...@apache.org
* Ross Gardlerrgard...@apache.org
* Sander van der Waal svanderw...@apache.org
* Scott Wilsonscot...@apache.org
* Sean Cooper secoo...@apache.org
* Suresh Marrusma...@apache.org
* Tony Carlucci   carlu...@apache.org
* Unico Hommesun...@apache.org
* Venkat Mahadevanvenk...@apache.org
* Woonsan Ko  woon...@apache.org
 
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matt Franklin
be appointed to the office of Vice President, Apache Rave, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
 
RESOLVED, that the initial Apache Rave PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Rave Project; and be it further
 
RESOLVED, that the Apache Rave Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Rave podling; and be it further
 
RESOLVED, that all responsibilities pertaining to the Apache
Incubator Rave podling encumbered upon the Apache Incubator
Project are hereafter discharged.
 
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] RAT Ready To Graduate As Apache Creadur Top Level Project

+1 - binding

Regards,
Alan

 
On Feb 26, 2012, at 8:03 AM, Robert Burrell Donkin wrote:

 The graduation guide[1] recommends that the Rat community demonstrates it's 
 willingness to govern itself through a free VOTE before asking the IPMC to 
 approve graduation. So, here it is :-)
 
 See [2] for a draft of the charter, excluding the list of initial committers. 
 Unless anyone jumps into this thread, I'll assume that the current list of 
 committers would be fine. Please read, review and jump in - but this is a 
 vote on the principle of graduating now.
 
 This VOTE is open to all, and I'll tally this no early than Wednesday, 29 Feb 
 2012 17:00 UTC.
 
 Robert
 
 --8---
 [ ] +1 the RAT community feels ready to graduate as Apache Creadur
 [ ] +0
 [ ] -0
 [ ] -1 Do not graduate RAT at this time
 ---
 
 
 [1] http://incubator.apache.org/guides/graduation.html#toplevel
 [2] Suggested Draft Charter:
 
   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software related to the comprehension and
   auditing of software distributions for distribution at
   no charge to the public.
 
   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Creadur Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further
 
   RESOLVED, that the Apache Creadur Project be and hereby is
   responsible for the creation and maintenance of open-source
   software related to the comprehension and auditing of software
   distributions for distribution at no charge to the public
 
   RESOLVED, that the office of Vice President, Apache Creadur be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache Creadur Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Creadur Project; and be it further
 
   RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache Creadur Project:
 
   ...
 
   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Robert Burrell
   Donkin be appointed to the office of Vice President, Apache
   Creadur, to serve in accordance with and subject to the
   direction of the Board of Directors and the Bylaws of the
   Foundation until death, resignation, retirement, removal or
   disqualification, or until a successor is appointed; and be
   it further
 
   RESOLVED, that the initial Apache Creadur PMC be and hereby is
   tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   Apache Creadur Project; and be it further
 
   RESOLVED, that the Apache Creadur Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator RAT podling; and be it further
 
   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator RAT podling encumbered upon the Apache Incubator
   Project are hereafter discharged.
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator


On Feb 28, 2012, at 11:39 AM, Alan D. Cabrera wrote:

 We should also give Arvind and the rest of the Sqoop community some
 indication how to proceed, given the voting period is completed.
 
 A concern has been raised by IPMC members and an effort is being made to 
 garner consensus.  The voting period is on hold.

Opps, I didn't see that Arvind concluded the vote.  I still stand by my opinion 
that there are some things that are not solely up to the people that are doing 
the work.  Complete migration to the the org.apache.* package space is one of 
them.

I ask the Apache Sqoop community to please remove the Cloudera packaged source 
code at their earliest convenience.

Regards,
Alan

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

 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.

The Sqoop community moved from github where it was ASL licensed to
Apache. There is now a Sqoop community at Apache that continues
using/developing this code and they felt that having backward
compatibility was useful. There is no stated restriction from Apache
against doing such. I don't know the cost of just dropping the
com.cloudera migration aids, but I suspect it would have been easier
to just drop it than spend the time worrying about it and trying to
provide a solution. I'm primarily acting as a mentor, Arvind would be
in better position to provide insight into that background and why the
community felt it was important to carry this forward.

Patrick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com wrote:

 On Feb 28, 2012, at 11:39 AM, Alan D. Cabrera wrote:

 We should also give Arvind and the rest of the Sqoop community some
 indication how to proceed, given the voting period is completed.

 A concern has been raised by IPMC members and an effort is being made to 
 garner consensus.  The voting period is on hold.

 Opps, I didn't see that Arvind concluded the vote.  I still stand by my 
 opinion that there are some things that are not solely up to the people that 
 are doing the work.  Complete migration to the the org.apache.* package space 
 is one of them.

No worries. I respect your opinion and if Apache feels that this is
important enough to make explicit then certainly Sqoop should make the
changes. Short of that I don't see why we should hold Sqoop to a
higher standard than is expected of other Apache projects. (that's
_my_ opinion ;-) )

Regards!

Patrick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 12:51 PM, Patrick Hunt ph...@apache.org wrote:
 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.

 The Sqoop community moved from github where it was ASL licensed to
 Apache. There is now a Sqoop community at Apache that continues
 using/developing this code and they felt that having backward
 compatibility was useful. There is no stated restriction from Apache
 against doing such. I don't know the cost of just dropping the
 com.cloudera migration aids, but I suspect it would have been easier
 to just drop it than spend the time worrying about it and trying to
 provide a solution. I'm primarily acting as a mentor, Arvind would be
 in better position to provide insight into that background and why the
 community felt it was important to carry this forward.

Thanks Patrick. You are absolutely right in stating that it would have
been easier for us to drop any backward compatibility requirements and
get releases out quickly. The reason we chose to invest a lot in
preserving backward compatibility is for our community. Sqoop has an
active community that we care deeply about and we have done our best
to make sure continues to use Sqoop effectively. It is this thriving
community that was the primary reason for Sqoop to have come into the
incubator in the first place.

One thing I want to clarify is that any insinuation that
com.cloudera.* packages exist in Sqoop is to somehow help Cloudera and
it's customers couldn't be farther from the truth. The fact is that
Cloudera will continue to provide support for Sqoop with backward
compatibility regardless of whether the com.cloudera.* namespace is
retained or removed from Sqoop. If we decided to remove these
packages, it is the community that will suffer, not Cloudera.

I do believe that if this is only an Incubator policy and not an
Apache policy, it will be tantamount to discrimination against the
Sqoop community more than anything else. To say that JSR specs are not
the same as old Cloudera code, gives me the impression that some
communities have more power on how Apache implements its policies for
larger communities than on smaller communities. If that is indeed the
case, it will help to state that explicitly.

Thanks,
Arvind Prabhakar


 Patrick

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Jukka Zitting

Hi,

On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
 On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com 
 wrote:
 Opps, I didn't see that Arvind concluded the vote.  I still stand by my 
 opinion that there
 are some things that are not solely up to the people that are doing the 
 work.  Complete
 migration to the the org.apache.* package space is one of them.

 No worries. I respect your opinion and if Apache feels that this is
 important enough to make explicit then certainly Sqoop should make the
 changes. Short of that I don't see why we should hold Sqoop to a
 higher standard than is expected of other Apache projects. (that's
 _my_ opinion ;-) )

Right.

Basically the graduation vote by the IPMC is about determining whether
the PPMC is capable of conducting itself according to the Apache Way
and Apache policies on it's own. I didn't have time to look deeper
into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
PPMC is ready to take on that responsibility. Along with that
responsibility comes the right to make value judgements on topics like
this where existing policies aren't clearly spelled out.

Personally I think we should let the vote result stand with guidance
to the new Sqoop PMC to discuss the matter with the branding team at
trademarks@ to seek Apache-wide consensus. I encourage anyone who
feels strongly about this (the point being made clearly has some
merit) make their case to trademarks@ as it's IMHO not really the task
of the Incubator to be forming new policy on this, especially with all
the recent talk about scaling down the ambitions of the IPMC.

BR,

Jukka Zitting

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
 On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com 
 wrote:
 Opps, I didn't see that Arvind concluded the vote.  I still stand by my 
 opinion that there
 are some things that are not solely up to the people that are doing the 
 work.  Complete
 migration to the the org.apache.* package space is one of them.

 No worries. I respect your opinion and if Apache feels that this is
 important enough to make explicit then certainly Sqoop should make the
 changes. Short of that I don't see why we should hold Sqoop to a
 higher standard than is expected of other Apache projects. (that's
 _my_ opinion ;-) )

 Right.

 Basically the graduation vote by the IPMC is about determining whether
 the PPMC is capable of conducting itself according to the Apache Way
 and Apache policies on it's own. I didn't have time to look deeper
 into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
 PPMC is ready to take on that responsibility. Along with that
 responsibility comes the right to make value judgements on topics like
 this where existing policies aren't clearly spelled out.

Thanks Jukka. In fact, Sqoop already has a plan in place to completely
remove com.cloudera.* namespace from its contents via the next major
revision of the product. The work for that has already started and
currently exists under the branch sqoop2 [3], tracked by SQOOP-365
[4]. We hope that in a few months time, we will have feature parity in
this branch with the trunk, which is when we will promote it to the
trunk.

[3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
[4] https://issues.apache.org/jira/browse/SQOOP-365


 Personally I think we should let the vote result stand with guidance
 to the new Sqoop PMC to discuss the matter with the branding team at
 trademarks@ to seek Apache-wide consensus. I encourage anyone who
 feels strongly about this (the point being made clearly has some
 merit) make their case to trademarks@ as it's IMHO not really the task
 of the Incubator to be forming new policy on this, especially with all
 the recent talk about scaling down the ambitions of the IPMC.

This sounds like a great solution that addresses the concern and does
not unduly penalize the Sqoop project. On behalf of Sqoop PMC, I will
be happy to take this up with the branding team and trademarks@ to
drive a definitive resolution. I also volunteer personally to discuss
and seek Apache-wide consensus on this issue for not only the benefit
of Sqoop, but for other projects who may be in this state inside or
outside of the Incubator.

Thanks,
Arvind Prabhakar


 BR,

 Jukka Zitting

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 11:25 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by my
 opinion that there
  are some things that are not solely up to the people that are doing the
 work.  Complete
  migration to the the org.apache.* package space is one of them.
 
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )

 Right.


It's not that anyone is holding Scoop to a higher standard. We just noticed
the issue now. I noticed because I'm a mentor on another project along side
Alan and since he posted I paid closer attention. I cannot and don't track
every podling. To be honest this is the first real encounter I've had with
Scoop. Sounds like something I could use :-) too. I want to see Scoop
graduate. I certainly don't want the Scoop guys thinking who's this jerk
getting in our way.

So I, nor the other's expressing concerns have anything against the Scoop
team. It's just chance that this project triggered the discussion. No one
is against Cloudera either. I don't know why people are bothering pointing
out the project came to the ASF Incubator from Github. Github is just a
repository. If you want to know where the code really came from then check
who the majority of contributors were before incubation. It makes no
difference: Cloudera or Github. The problem for us still persists.


 Basically the graduation vote by the IPMC is about determining whether
 the PPMC is capable of conducting itself according to the Apache Way
 and Apache policies on it's own.


I don't understand the rush to graduate. What difference does a month make
in the grand scheme of things? The sudden vehement push to include these
packages worries me. Graduating should not be more important than
addressing valid concerns.


 I didn't have time to look deeper
 into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
 PPMC is ready to take on that responsibility.


Rather than crudely drop a -1 we voiced our concerns as IPMC members, and
mentors to open up discussion about the matter. It's easy to drop the
package and solve the technical problem. If you need a -1 to stop the
process then you have mine.


 Along with that
 responsibility comes the right to make value judgements on topics like
 this where existing policies aren't clearly spelled out.


Honestly I've begun to be concerned after watching how vehemently the
Cloudera people came out of the woodwork to push graduation no matter what
concerns were expressed. IMHO that's not in line with the Apache Way as
far as our culture goes. So yes the impatience is triggering me to be
doubtful of their ability to handle the responsibility. At the end of the
day no project is more important than the ASF as a whole.


 Personally I think we should let the vote result stand with guidance
 to the new Sqoop PMC to discuss the matter with the branding team at
 trademarks@ to seek Apache-wide consensus. I encourage anyone who
 feels strongly about this (the point being made clearly has some
 merit) make their case to trademarks@ as it's IMHO not really the task
 of the Incubator to be forming new policy on this, especially with all
 the recent talk about scaling down the ambitions of the IPMC.


That's a good point and to a really large extent I agree with you. However
this is one of the last lines of defense we have before it becomes much
harder to rectify. While we have the issue on the radar let's take care of
it now. That will provide more drive to resolve it quickly.

So I'd rather get clarification on this grey area ASAP. I certainly cannot
brush it under the rug after noticing it. So let's play it safe, get some
resolution, then proceed forward. That's the best approach IMHO. Graduation
will occur in the near future so let's not sweat it.

-- 
Best Regards,
-- Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.orgwrote:

 On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Hi,
 
  On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by
 my opinion that there
  are some things that are not solely up to the people that are doing
 the work.  Complete
  migration to the the org.apache.* package space is one of them.
 
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )
 
  Right.
 
  Basically the graduation vote by the IPMC is about determining whether
  the PPMC is capable of conducting itself according to the Apache Way
  and Apache policies on it's own. I didn't have time to look deeper
  into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
  PPMC is ready to take on that responsibility. Along with that
  responsibility comes the right to make value judgements on topics like
  this where existing policies aren't clearly spelled out.

 Thanks Jukka. In fact, Sqoop already has a plan in place to completely
 remove com.cloudera.* namespace from its contents via the next major
 revision of the product. The work for that has already started and
 currently exists under the branch sqoop2 [3], tracked by SQOOP-365
 [4]. We hope that in a few months time, we will have feature parity in
 this branch with the trunk, which is when we will promote it to the
 trunk.

 [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
 [4] https://issues.apache.org/jira/browse/SQOOP-365

 
  Personally I think we should let the vote result stand with guidance
  to the new Sqoop PMC to discuss the matter with the branding team at
  trademarks@ to seek Apache-wide consensus. I encourage anyone who
  feels strongly about this (the point being made clearly has some
  merit) make their case to trademarks@ as it's IMHO not really the task
  of the Incubator to be forming new policy on this, especially with all
  the recent talk about scaling down the ambitions of the IPMC.

 This sounds like a great solution that addresses the concern and does
 not unduly penalize the Sqoop project.


You really should not be seeing this as being penalized. It's not about
that.

Alex

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

On Tue, Feb 28, 2012 at 2:50 PM, Alex Karasulu akaras...@apache.org wrote:
 On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.orgwrote:

 On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Hi,
 
  On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by
 my opinion that there
  are some things that are not solely up to the people that are doing
 the work.  Complete
  migration to the the org.apache.* package space is one of them.
 
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )
 
  Right.
 
  Basically the graduation vote by the IPMC is about determining whether
  the PPMC is capable of conducting itself according to the Apache Way
  and Apache policies on it's own. I didn't have time to look deeper
  into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
  PPMC is ready to take on that responsibility. Along with that
  responsibility comes the right to make value judgements on topics like
  this where existing policies aren't clearly spelled out.

 Thanks Jukka. In fact, Sqoop already has a plan in place to completely
 remove com.cloudera.* namespace from its contents via the next major
 revision of the product. The work for that has already started and
 currently exists under the branch sqoop2 [3], tracked by SQOOP-365
 [4]. We hope that in a few months time, we will have feature parity in
 this branch with the trunk, which is when we will promote it to the
 trunk.

 [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
 [4] https://issues.apache.org/jira/browse/SQOOP-365

 
  Personally I think we should let the vote result stand with guidance
  to the new Sqoop PMC to discuss the matter with the branding team at
  trademarks@ to seek Apache-wide consensus. I encourage anyone who
  feels strongly about this (the point being made clearly has some
  merit) make their case to trademarks@ as it's IMHO not really the task
  of the Incubator to be forming new policy on this, especially with all
  the recent talk about scaling down the ambitions of the IPMC.

 This sounds like a great solution that addresses the concern and does
 not unduly penalize the Sqoop project.


 You really should not be seeing this as being penalized. It's not about
 that.

The penalty I reference is for the Sqoop community which will be
impacted by incompatible changes you are suggesting.

I appreciate your feedback, and request that you keep the discussion
relavant to the issue at hand without making references like Cloudera
people come out of the woodwork. Please understand that we interact
with Apache as individual contributors and committers. Such references
undermine our efforts and are honestly insulting to everyone who has
spent hours on delivering the product.

Thanks,
Arvind Prabhakar



 Alex

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

Hi all...

   I don't think that anyone here is trying to underestimate or saying
anything bad about Sqoop in general or about Cloudera people in particular.

And I agree on the point that this vote was more about evaluating whether
the Sqoop community succeeded to adapt to the Apache way of doing open
source software or not, and I still believe that they did very good job. So
lets not get into this by any how!!!

On the other hand, I totally respect that Cloudera's interest to support
their customers and provide backword compatibility, but this is *not* the
point at all, the point is this *should* not, and even allow me to say this
is *must* not be the problem of Apache, and yes I agree with the opinion
that this is a matter to be decided by Sqoop team but not to make Apache's
problem. So also let not get more into this!!!

Even if there is no explicit rules about that, which is something I really
have to look into, again I believe it shouldn't be Apache's problem and if
thats the case the relevant documents should be updated and on behalf on
others, sorry if I am speaking in name of others here, but I thank the
Sqoop team to bring that issue so we know that we need to make things more
clear and precise which is also the role of IPMC as part of Apache.

IMHO lets be pragmatic and cut into the chase and seek answers and
solutions. As I stated before, but I still didn't get any answers, how much
of work this needs to get it done ?

I will assume two available answers:

1- It can be done before the next board meeting and hence there is no
problem at all and the vote still valid.
2- If not, we have two options:
  2.1 We still make the vote valid but Mentors they *must* make sure that
such issue is resolved as a checklist item of the graduation process steps,
which I would prefer
  2.2 Vote is cancelled and required changes are discussed by the PPMC
preparing for the next vote iteration

I would urge all involved to focus on these options or other options if
available, the whole purpose here is to make things better, to make Apache
way better and more clear which is not only the role of IPMC but it is the
role of everyone involved with Apache including Sqoop community itself,
which I am sure they are willing to help as much as possible.

Sorry for the long e-mail :)

Looking forward to your reply!

On Wed, Feb 29, 2012 at 12:18 AM, Alex Karasulu akaras...@apache.orgwrote:

 On Wed, Feb 29, 2012 at 12:59 AM, Arvind Prabhakar arv...@apache.org
 wrote:

  On Tue, Feb 28, 2012 at 2:50 PM, Alex Karasulu akaras...@apache.org
  wrote:
   On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.org
  wrote:
  
   On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting 
 jukka.zitt...@gmail.com
  
   wrote:
Hi,
   
On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org
  wrote:
On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera 
  a...@toolazydogs.com
   wrote:
Opps, I didn't see that Arvind concluded the vote.  I still stand
 by
   my opinion that there
are some things that are not solely up to the people that are
 doing
   the work.  Complete
migration to the the org.apache.* package space is one of them.
   
No worries. I respect your opinion and if Apache feels that this is
important enough to make explicit then certainly Sqoop should make
  the
changes. Short of that I don't see why we should hold Sqoop to a
higher standard than is expected of other Apache projects. (that's
_my_ opinion ;-) )
   
Right.
   
Basically the graduation vote by the IPMC is about determining
 whether
the PPMC is capable of conducting itself according to the Apache Way
and Apache policies on it's own. I didn't have time to look deeper
into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
PPMC is ready to take on that responsibility. Along with that
responsibility comes the right to make value judgements on topics
 like
this where existing policies aren't clearly spelled out.
  
   Thanks Jukka. In fact, Sqoop already has a plan in place to completely
   remove com.cloudera.* namespace from its contents via the next major
   revision of the product. The work for that has already started and
   currently exists under the branch sqoop2 [3], tracked by SQOOP-365
   [4]. We hope that in a few months time, we will have feature parity in
   this branch with the trunk, which is when we will promote it to the
   trunk.
  
   [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
   [4] https://issues.apache.org/jira/browse/SQOOP-365
  
   
Personally I think we should let the vote result stand with guidance
to the new Sqoop PMC to discuss the matter with the branding team at
trademarks@ to seek Apache-wide consensus. I encourage anyone who
feels strongly about this (the point being made clearly has some
merit) make their case to trademarks@ as it's IMHO not really the
  task
of the Incubator to be forming new

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

2012-02-28 Thread Daniel Kulp


We had a very similar discussion about the back word compatibility 
classes/package names when Subversion graduated and we deemed it OK for them.   
In fact, I believe they still of org.tigris packages in their codebase long 
after graduation.   See:

http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/src/org/


I don't see why we would or should hold Sqoop to a different or higher 
standard at this point.   I agree with Jukka that if we, as a foundation, 
would like to re-address this, fine, take it to trademarks@ and start a 
discussion.   However, from an INCUBATOR standpoint, the precedent and 
expectations have  been set.

That's my $0.02 cents worth.

Dan



On Tuesday, February 28, 2012 10:25:41 PM Jukka Zitting wrote:
 Hi,
 
 On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com 
wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by my
  opinion that there are some things that are not solely up to the people
  that are doing the work.  Complete migration to the the org.apache.*
  package space is one of them.
  
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )
 
 Right.
 
 Basically the graduation vote by the IPMC is about determining whether
 the PPMC is capable of conducting itself according to the Apache Way
 and Apache policies on it's own. I didn't have time to look deeper
 into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
 PPMC is ready to take on that responsibility. Along with that
 responsibility comes the right to make value judgements on topics like
 this where existing policies aren't clearly spelled out.
 
 Personally I think we should let the vote result stand with guidance
 to the new Sqoop PMC to discuss the matter with the branding team at
 trademarks@ to seek Apache-wide consensus. I encourage anyone who
 feels strongly about this (the point being made clearly has some
 merit) make their case to trademarks@ as it's IMHO not really the task
 of the Incubator to be forming new policy on this, especially with all
 the recent talk about scaling down the ambitions of the IPMC.
 
 BR,
 
 Jukka Zitting
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

Hi Daniel...

On Wed, Feb 29, 2012 at 1:07 AM, Daniel Kulp dk...@apache.org wrote:


 We had a very similar discussion about the back word compatibility
 classes/package names when Subversion graduated and we deemed it OK for
 them.
 In fact, I believe they still of org.tigris packages in their codebase long
 after graduation.   See:


 http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/src/org/


 I don't see why we would or should hold Sqoop to a different or higher
 standard at this point.   I agree with Jukka that if we, as a foundation,
 would like to re-address this, fine, take it to trademarks@ and start a
 discussion.   However, from an INCUBATOR standpoint, the precedent and
 expectations have  been set.

 That's my $0.02 cents worth.


Thanks a lot for this, but would you elaborate more on why this has been
accepted ? My believe is that there is some clarification that should be
added to documentation so it is more clear for all people in the future,
your input on this example would help indeed.


 Dan



 On Tuesday, February 28, 2012 10:25:41 PM Jukka Zitting wrote:
  Hi,
 
  On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
   On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 
 wrote:
   Opps, I didn't see that Arvind concluded the vote.  I still stand by
 my
   opinion that there are some things that are not solely up to the
 people
   that are doing the work.  Complete migration to the the org.apache.*
   package space is one of them.
  
   No worries. I respect your opinion and if Apache feels that this is
   important enough to make explicit then certainly Sqoop should make the
   changes. Short of that I don't see why we should hold Sqoop to a
   higher standard than is expected of other Apache projects. (that's
   _my_ opinion ;-) )
 
  Right.
 
  Basically the graduation vote by the IPMC is about determining whether
  the PPMC is capable of conducting itself according to the Apache Way
  and Apache policies on it's own. I didn't have time to look deeper
  into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
  PPMC is ready to take on that responsibility. Along with that
  responsibility comes the right to make value judgements on topics like
  this where existing policies aren't clearly spelled out.
 
  Personally I think we should let the vote result stand with guidance
  to the new Sqoop PMC to discuss the matter with the branding team at
  trademarks@ to seek Apache-wide consensus. I encourage anyone who
  feels strongly about this (the point being made clearly has some
  merit) make their case to trademarks@ as it's IMHO not really the task
  of the Incubator to be forming new policy on this, especially with all
  the recent talk about scaling down the ambitions of the IPMC.
 
  BR,
 
  Jukka Zitting
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Thanks
- Mohammad Nour

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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator