As another point of reference, there is at least one case I'm aware of where we HAD to put some code developed at Apache into non-org.apache namespace in order for the code to work. This was taken up on legal discuss and, at the time, no issues about doing so were raised.
See: http://s.apache.org/WzP And the CXF bug: https://issues.apache.org/jira/browse/CXF-1880 In this case, it was new code developed at Apache and in the org.apache.cxf namespace, but in order for the code to actual work, there were shims necessary in com.sun. Now, this is a slightly different case in that no end-users would likely ever call (or really even see) this code. It's just need to plugin into an external tool. So, IMO, code at Apache SHOULD be developed in the org.apache namespace, but projects need to be able to have some flexibility to use their judgment to figure out what is best for the needs of their community. Projects should be encouraged to keep code outside org.apache to a minimum via shims or similar and also encourage end users to migrate to using the code in the org.apache namespace as soon as possible. Dan On Wednesday, February 29, 2012 11:02:33 AM Mohammad Nour El-Din wrote: > I don't see that this getting to any clear end yet. So I suggest that we > take this from a Sqoop instance to be a discussion on rules them selves. > > I would like to start a [VOTE] about whether it is a *must* for podlings to > rename all packages before being a TLP or not over keeping the old package > names for backward compatibility. What ever the consensus going to be built > we definitely need to update the Incubator documents to clear this kind of > issue. But before starting the vote I would like to consider others' > opinions. > > Thoughts ? > > On Wed, Feb 29, 2012 at 10:33 AM, Alex Karasulu <akaras...@apache.org>wrote: > > On Wed, Feb 29, 2012 at 2:40 AM, Patrick Hunt <ph...@apache.org> wrote: > > > On Tue, Feb 28, 2012 at 4:02 PM, Mohammad Nour El-Din > > > > > > <nour.moham...@gmail.com> wrote: > > > > 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!!! > > > > > > Or course this is Apache's problem. You can't have your cake and eat > > > it too. If you accept code for a project you accept the community as > > > well. Say Apache accepts a project like Open Office, should we ignore > > > the existing community and not concern ourselves with backward > > > compatibility for that project as well, because the original code > > > wasn't birthed at Apache? > > > > That's a very slippery slope. Maybe some projects get way too much leeway > > because of the big flashing lights. Regardless of how big the press > > headlines are all projects should be held to the same standard. > > > > No project should be allowed to graduate without solving all issues > > pertaining to marks. It's a failure of the incubator in the past for > > allowing other projects to do so. I'm shocked it was allowed. > > > > -- > > Best Regards, > > -- Alex -- 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
