Hi Greg... On Wed, Feb 29, 2012 at 1:06 PM, Greg Stein <gst...@gmail.com> wrote:
> On Feb 29, 2012 4:15 AM, "Alex Karasulu" <akaras...@apache.org> wrote: > > > > On Wed, Feb 29, 2012 at 4:06 AM, Daniel Kulp <dk...@apache.org> wrote: > > > > > On Wednesday, February 29, 2012 1:13:30 AM Mohammad Nour El-Din wrote: > > > > 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/javah > > > > > l/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. > > > > > > You could likely read the mail archives if you want all the details. > > > general@incubator in Nov 2009 had a thread, dev@subversion in Jan > 2010 > > > had a > > > thread, and I think the graduation vote in Feb 2010 had more > discussions. > > > > > > Basically, the Subversion had binary compatibility "rules" and there > was no > > > real "legal" requirement to force a huge disruption in the community by > > > changing the package names. The project had a plan to deprecate > > > them/create > > > wrappers/whatever so when it was appropriate to break compatibility > they > > > would. > > > > > > > > Did they remove those packages or did they remain? > > They remain. > > Keeping them is the right thing for our community and product. That is our > determination, and is our Right. > That is what we are trying to figure out here, and that is why we have this discussion :) > > Sqoop has determined backwards compatibility is important to their > community and wants to keep this (deprecated) interface for a while. So > where is the problem here, people? > > Really. What is the problem with the extra interfaces? > No body is trying to make any problems to any other one here, we are just trying to make sure that things are done as it should be > > There is no legal (trademark or copyright) problem that I'm aware of. There > is no technical problem that I'm aware of. So what is it? Why are people > all up in Sqoop's face here? Why is there some attempt at imposing > technical changes on them? What ASF-wide policy is being broken? If the > policy doesn't exist, but you think it *should*, then please state as much, > along with a resolution for the Board to consider, in order to make it > official policy. And if/when the Board *does* make it official policy, then > the graduated/TLP PMC can ensure their code base complies. > Again and as I started in one of my earlier e-mails, no one is trying to impose anything on Sqoop or any other project, it is something that needs to be discussed and thats all, and the vote neither cancelled nor postponed, we still have time till next board meeting and we here trying to sort things out to see, as you also explained below, if it is a real issue which needs to be raised to the board or not, if not then there is nothing to talk about and thing will go as planned for Sqoop or any other podling will propose for being graduated in the future. So I agree with you it is not a Sqoop thing at all it is more about ASF itself. > > And please note: this imputed/proposed policy will affect Subversion > packaging, too. Your rationale for mandates on Sqoop package names must be > able to apply just as well to Subversion. Don't focus on just Sqoop, but > the overall Foundation-wide issue. If you send a resolution to the Board, > then it better be backed up with an explanation of why the Board should be > getting involved in Java package naming for projects across the Foundation. > The explanation should state the problem, and how the policy (via the > resolution) will solve that problem. > Totally agree, and again we are still discussing if it should be raised to the board and then stated and an ASF policy or not, and in the former case sure there must plans for already existing projects how to adapt to that and sure giving them the proper time window, but again there is no reason going into this hassle if there is no consensus on making an issue out of it. > > I see no reason for the Incubator to reverse a vote that has been > completed, and to do so in the name of some nebulous/unstated policy. It is > exactly this behavior why projects want to graduate earlier rather than > later. To escape random, misplaced imposition on communities. > Again :), no body is reserving that vote here. Again I feel that, and sorry for saying that, wasting a lot of time with no real result, some people say it is not an issue and give examples about projects already graduated with the same *issue* under discussion, I use issue in a general term, and some other people say it is an issue and I am sure they can give examples of projects which did not graduate till they solved that in their code. I gave it more thought and IMO, I think we should raise the issue to the Board to get to some results, but at the same time we should not stop Sqoop from graduation, and if it turned out that there should be some policy to clear that out then Sqoop, among other projects, can do the required changes within a proper time window that can be discussed per project or as general time window for all TLP projects in ASF, and for sure it would be a *must* have exit criteria for polding projects. If it is not an issue then as if nothing happened. But in either case there should be more clear and precise documentations not to get into this situation again. If everybody agree on this idea I would volunteer to raise this issue to the board, but I would appreciate some hints about hot to do so :) ? > > -g > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
