Thanks everyone for the feedback!
-Matt
On Mon, Aug 10, 2015 at 9:55 AM, Chris Nauroth
wrote:
> Consideration of end user impact is a great point, and perhaps the most
> important consideration. In the case of DataFu, others have brought up
> that the rename would be a backwards-incompatible c
Consideration of end user impact is a great point, and perhaps the most
important consideration. In the case of DataFu, others have brought up
that the rename would be a backwards-incompatible change that breaks all
existing client scripts that use DataFu, and going forward such a change
would cau
I think you should consider the impact and potential gain on a
per-project basis, and agree this within the podling. I don't think we
can prescribe one way or the other for every project.
Changing the package name can for Java developers be a bit of an
identity thing and help to level the playing
For incubator projects, I strongly suggest renames unless there is a
compelling counter argument.
I think that many others would make similar suggestions, but doubt that
there is explicit policy on this.
On Sun, Aug 9, 2015 at 6:28 PM, Roman Shaposhnik
wrote:
> Thank you all for the feedback.
Thank you all for the feedback. This is super helpful!
One question that I still have is this: do we have a bias
for suggesting package rename or any package name
can remain in place?
Thanks,
Roman.
On Sat, Aug 8, 2015 at 2:25 AM, Andy Seaborne wrote:
> Hi,
>
> Jena graduated 2012 with old name
Hi,
Jena graduated 2012 with old namespaces under com.hp.hpl.jena, and some
under org.openjena, with an intention to change at the first major
release update. As new packages came along, they went into
org.apache.jena but the user facing packages remained where they were.
We released Jena 3
Jakob,
I was curious about you statement about Kafka so I went and looked.
I only looked at the client code, but it appears that it is all under
org.apache.kafka.
Can you say more about what you meant by "Kafka has done fine without doing
so"?
On Fri, Aug 7, 2015 at 9:53 PM, Jakob Homan wrot
There is no reason to change the packages. Kafka has done fine
without doing so, as has been OpenNLP. There are no commercial or
vendor concerns. There is no legal requirement to do so. It's a
purely technical issue (how Java happens to organize code).
-jakob
On 7 August 2015 at 21:41, Nicla
By that notion, practically all incoming projects would be in non
org.apache namespaces, and that would be a different kind of detrimental
situation.
So, my(!) general recommendation has been; for any releases that maintain
100% compatibility, keep the namespace as before. But as soon as a major
(
+1. Pig scripts are written by hand, mostly by data scientists with modest
software skills, so asking them to change all their scripts is both painful
and annoying with no real benefit.
On Fri, Aug 7, 2015 at 3:55 PM, Russell Jurney
wrote:
> Leave it datafu. The normal way of doing Java namespac
Leave it datafu. The normal way of doing Java namespaces is terrible bloat,
and the change would be breaking.
On Friday, August 7, 2015, Luciano Resende wrote:
> On Fri, Aug 7, 2015 at 3:16 PM, Matthew Hayes <
> matthew.terence.ha...@gmail.com > wrote:
>
> > Hi all,
> >
> > Roman Shaposhnik sugg
On Fri, Aug 7, 2015 at 3:16 PM, Matthew Hayes <
matthew.terence.ha...@gmail.com> wrote:
> Hi all,
>
> Roman Shaposhnik suggested I open a discussion on the following topic:
>
> For Apache DataFu, all of the Java classes are declared in a datafu.*
> namespace. This has been the naming convention s
12 matches
Mail list logo
