incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
Date Wed, 29 Feb 2012 14:00:30 GMT
On Feb 29, 2012 8:34 AM, "Ian Dickinson" <ian@epimorphics.com> wrote:
>
> On 29/02/12 10:02, 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 ?
>
> In the case of Apache Jena (incubating), we have more than ten years'
worth of existence as an open-source project. In that time, there have been
countless tutorials, articles, research papers, code snippets, books and
add-on tools that make use of Jena code in the com.hp namespace. But Jena
was never an HP *product*, it was an output from the HP research lab in the
UK.
>
> Our intention as Apache project has been much like Sqoop's: to migrate to
org.apache names but keep a compatibility layer in place. We had thought
that migration wasn't necessary for graduation, but if it is, no biggie.
What would be problematic for our community is if we can't host the
compatibility layer packages *at all* under Apache. If we have to expunge
all references to com.hp.* packages, then all that back-catalogue of
tutorials etc will be instantly obsolete ... unless folks know to go and
separately download the jena-compatibility package from SourceForge or
wherever it would hypothetically end up.
>
> Some of the discussion around Sqoop has been that the
backwards-compatibility requirement is all about Cloudera's customers so
it's Cloudera's problem. In the case of Jena, it has never been about HP's
customers, and it definitely isn't HP's problem since none of the current
committers work there any more.

For Subversion, Craig Russell was concentrating on this aspect while we
were incubating. He basically said, "no problem with graduation, as long as
you have a plan in place." He followed up with an email about 18 months
after graduation, and I replied, "yup, all moved over."

Moving to org.apache.subversion gave us an opportunity to revamp our
interfaces based on what we had learned from the first go-round in
org.tigris.subversion. So we have the new hot interfaces under o.a.s, and
the compat layer under o.t.s. Works great.

Cheers,
-g

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