Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)

2019-06-18 Thread Adrian Cole 
of course I meant "packages released as a *not* super high priority concern"

On Tue, Jun 18, 2019, 5:37 PM Adrian Cole  wrote:

> if you would like to do, this feel free. this type of concern seems more
> like a github issue vs an incubator discussion. we have changed group ids
> in the past prior to Apache without complaints.
>
> again the most important project from a dependency pinning pov, brave, was
> never released. knowing the community as I do I would rate the other
> packages released as a super high priority concern these are low level or
> niche libraries. it would have been a problem if we released brave but we
> didn't luckily.
>
> On Tue, Jun 18, 2019, 5:33 PM sebb  wrote:
>
>> On Tue, 18 Jun 2019 at 00:40, Adrian Cole 
>> wrote:
>> >
>> > on the maven topic:
>> >
>> > for almost all cases there will be no classpath problem. the most common
>> > entry point into maven was the package for "brave" which was never
>> released
>> > under an apache group id. the underlying libraries had very few call
>> sites
>> > in comparison. the "bom" most commonly used was also never released.
>>
>> There appear to be at least 7 Maven packages under org.apache.zipkin.
>> These have been released, and cannot be changed.
>>
>> I don't know if any of them have been used by 3rd parties, but if they
>> have:
>>
>> If any of them use the same Java package name as io.zipkin Maven
>> packages, then there is a chance that two jars with the same class
>> names but different API and behaviour will end up on the classpath.
>> This can cause failures that can be hard to debug.
>>
>> > the server itself was explicitly marked as not supported as a library,
>> so
>> > there is not much impact to group ids there. many didn't upgrade to the
>> ASF
>> > build according to support chatter. like most projects, getting folks to
>> > upgrade is a task in itself.
>> >
>> > main thing, we will take this liability of group ids on as a community
>> in
>> > other words, and it is less a problem than being unable to control our
>> > repositories which is the current dilemma. you dont need to worry about
>> > this.
>>
>> This is not about who controls the entries in Maven Central.
>> It is about ensuring that Maven knows which jars can safely co-exist
>> on the classpath.
>>
>> It may help the project to set up a relocation POM.
>> AIUI this may help Maven to know that org.apache.zipkin is now
>> io.zipkin, and thus hopefully prevent both appearing on the same
>> classpath.
>>
>> > On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:
>> >
>> > > I agree it's not a block, but there is scope for some classpath
>> confusion.
>> > >
>> > > If someone has an app that includes both the ASF and non-ASF Zipkin
>> > > jars, both will end up on the Maven classpath.
>> > > There is no way to tell which version of a particular class will end
>> > > up being loaded.
>> > >
>> > > A Maven relocation pom might help to ensure that only one version of
>> > > the jars ends up on the Maven classpath, but I've not tried that.
>> > >
>> > > The recommended procedure is to always ensure that there is a 1:1
>> > > relationship between Maven coords and Java package name.
>> > > There can then be no chance of incompatible jars on the classpath.
>> > >
>> > > On Mon, 17 Jun 2019 at 14:17, Sheng Wu 
>> wrote:
>> > > >
>> > > > Hi
>> > > > Zipkin doesn’t change the java package name, and had no plan to do
>> that.
>> > > > We just changed the groupid, and are reverting it back to
>> `io.zipkin`.
>> > > >
>> > > > So, I don’t see this as a block.
>> > > >
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)

2019-06-18 Thread Adrian Cole 
if you would like to do, this feel free. this type of concern seems more
like a github issue vs an incubator discussion. we have changed group ids
in the past prior to Apache without complaints.

again the most important project from a dependency pinning pov, brave, was
never released. knowing the community as I do I would rate the other
packages released as a super high priority concern these are low level or
niche libraries. it would have been a problem if we released brave but we
didn't luckily.

On Tue, Jun 18, 2019, 5:33 PM sebb  wrote:

> On Tue, 18 Jun 2019 at 00:40, Adrian Cole  wrote:
> >
> > on the maven topic:
> >
> > for almost all cases there will be no classpath problem. the most common
> > entry point into maven was the package for "brave" which was never
> released
> > under an apache group id. the underlying libraries had very few call
> sites
> > in comparison. the "bom" most commonly used was also never released.
>
> There appear to be at least 7 Maven packages under org.apache.zipkin.
> These have been released, and cannot be changed.
>
> I don't know if any of them have been used by 3rd parties, but if they
> have:
>
> If any of them use the same Java package name as io.zipkin Maven
> packages, then there is a chance that two jars with the same class
> names but different API and behaviour will end up on the classpath.
> This can cause failures that can be hard to debug.
>
> > the server itself was explicitly marked as not supported as a library, so
> > there is not much impact to group ids there. many didn't upgrade to the
> ASF
> > build according to support chatter. like most projects, getting folks to
> > upgrade is a task in itself.
> >
> > main thing, we will take this liability of group ids on as a community in
> > other words, and it is less a problem than being unable to control our
> > repositories which is the current dilemma. you dont need to worry about
> > this.
>
> This is not about who controls the entries in Maven Central.
> It is about ensuring that Maven knows which jars can safely co-exist
> on the classpath.
>
> It may help the project to set up a relocation POM.
> AIUI this may help Maven to know that org.apache.zipkin is now
> io.zipkin, and thus hopefully prevent both appearing on the same
> classpath.
>
> > On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:
> >
> > > I agree it's not a block, but there is scope for some classpath
> confusion.
> > >
> > > If someone has an app that includes both the ASF and non-ASF Zipkin
> > > jars, both will end up on the Maven classpath.
> > > There is no way to tell which version of a particular class will end
> > > up being loaded.
> > >
> > > A Maven relocation pom might help to ensure that only one version of
> > > the jars ends up on the Maven classpath, but I've not tried that.
> > >
> > > The recommended procedure is to always ensure that there is a 1:1
> > > relationship between Maven coords and Java package name.
> > > There can then be no chance of incompatible jars on the classpath.
> > >
> > > On Mon, 17 Jun 2019 at 14:17, Sheng Wu 
> wrote:
> > > >
> > > > Hi
> > > > Zipkin doesn’t change the java package name, and had no plan to do
> that.
> > > > We just changed the groupid, and are reverting it back to
> `io.zipkin`.
> > > >
> > > > So, I don’t see this as a block.
> > > >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Maven coordinates (was: Move the Zipkin repos back, as the community has voted to leave.)

2019-06-18 Thread sebb 
On Tue, 18 Jun 2019 at 00:40, Adrian Cole  wrote:
>
> on the maven topic:
>
> for almost all cases there will be no classpath problem. the most common
> entry point into maven was the package for "brave" which was never released
> under an apache group id. the underlying libraries had very few call sites
> in comparison. the "bom" most commonly used was also never released.

There appear to be at least 7 Maven packages under org.apache.zipkin.
These have been released, and cannot be changed.

I don't know if any of them have been used by 3rd parties, but if they have:

If any of them use the same Java package name as io.zipkin Maven
packages, then there is a chance that two jars with the same class
names but different API and behaviour will end up on the classpath.
This can cause failures that can be hard to debug.

> the server itself was explicitly marked as not supported as a library, so
> there is not much impact to group ids there. many didn't upgrade to the ASF
> build according to support chatter. like most projects, getting folks to
> upgrade is a task in itself.
>
> main thing, we will take this liability of group ids on as a community in
> other words, and it is less a problem than being unable to control our
> repositories which is the current dilemma. you dont need to worry about
> this.

This is not about who controls the entries in Maven Central.
It is about ensuring that Maven knows which jars can safely co-exist
on the classpath.

It may help the project to set up a relocation POM.
AIUI this may help Maven to know that org.apache.zipkin is now
io.zipkin, and thus hopefully prevent both appearing on the same
classpath.

> On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:
>
> > I agree it's not a block, but there is scope for some classpath confusion.
> >
> > If someone has an app that includes both the ASF and non-ASF Zipkin
> > jars, both will end up on the Maven classpath.
> > There is no way to tell which version of a particular class will end
> > up being loaded.
> >
> > A Maven relocation pom might help to ensure that only one version of
> > the jars ends up on the Maven classpath, but I've not tried that.
> >
> > The recommended procedure is to always ensure that there is a 1:1
> > relationship between Maven coords and Java package name.
> > There can then be no chance of incompatible jars on the classpath.
> >
> > On Mon, 17 Jun 2019 at 14:17, Sheng Wu  wrote:
> > >
> > > Hi
> > > Zipkin doesn’t change the java package name, and had no plan to do that.
> > > We just changed the groupid, and are reverting it back to `io.zipkin`.
> > >
> > > So, I don’t see this as a block.
> > >

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

Re: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Sheng Wu 
Hi

I am going to start the VOTE, let’s quickly response on that.
From my understanding, there is no meaning to still hold the community.

Please be advised, 
Zipkin is just “Retire” from the ASF incubator, not really retire as OSS 
project.
The community is waiting.

Sheng Wu
Apache Skywalking, ShardingSphere, Zipkin



> 在 2019年6月18日，上午4:28，Dave Fisher  写道：
> 
> Hi -
> 
> A retirement VOTE on general@ is required. [1] This is the last formality 
> required. Incubation is not for every project.
> 
> Then follow [2] as much as possible, but with the exception of transferring 
> the repositories back to OpenZipken. In addition the IPMC will request that 
> INFRA make read-only RETIRED clones of each repository. 
> 
> Regards,
> Dave
> 
> [1] https://incubator.apache.org/guides/retirement.html#deciding_to_retire
> [2] https://incubator.apache.org/guides/retirement.html#steps_to_retirement
> 
>> On Jun 17, 2019, at 2:52 AM, Sheng Wu  wrote:
>> 
>> Hi Incubator.
>> 
>> As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
>> back to original OpenZipkin org as soon as possible.
>> 
>> They have done a public ml vote, result is here[1].
>> Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
>> there is no such thing about return the trademark or permission of using 
>> Zipkin name.
>> 
>> Zipkin is a big community and a lots of dependency out there are waiting for 
>> release.
>> 
>> I think there is nothing hold this transfer, right?
>> If so, please give a clear reply. The INFRA team is waiting at this JIRA 
>> ticket[2].
>> 
>> 
>> [1] 
>> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
>>  
>> 
>> [2] https://issues.apache.org/jira/browse/INFRA-18604 
>> 
>> 
>> 
>> Sheng Wu
>> Apache Skywalking, ShardingSphere, Zipkin
>> 
>> 
>> 
> 
> 
> -
> 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: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Adrian Cole 
on the maven topic:

for almost all cases there will be no classpath problem. the most common
entry point into maven was the package for "brave" which was never released
under an apache group id. the underlying libraries had very few call sites
in comparison. the "bom" most commonly used was also never released.

the server itself was explicitly marked as not supported as a library, so
there is not much impact to group ids there. many didn't upgrade to the ASF
build according to support chatter. like most projects, getting folks to
upgrade is a task in itself.

main thing, we will take this liability of group ids on as a community in
other words, and it is less a problem than being unable to control our
repositories which is the current dilemma. you dont need to worry about
this.

On Tue, Jun 18, 2019, 4:13 AM sebb  wrote:

> I agree it's not a block, but there is scope for some classpath confusion.
>
> If someone has an app that includes both the ASF and non-ASF Zipkin
> jars, both will end up on the Maven classpath.
> There is no way to tell which version of a particular class will end
> up being loaded.
>
> A Maven relocation pom might help to ensure that only one version of
> the jars ends up on the Maven classpath, but I've not tried that.
>
> The recommended procedure is to always ensure that there is a 1:1
> relationship between Maven coords and Java package name.
> There can then be no chance of incompatible jars on the classpath.
>
> On Mon, 17 Jun 2019 at 14:17, Sheng Wu  wrote:
> >
> > Hi
> > Zipkin doesn’t change the java package name, and had no plan to do that.
> > We just changed the groupid, and are reverting it back to `io.zipkin`.
> >
> > So, I don’t see this as a block.
> >
> > Sheng Wu
> > Apache Skywalking, ShardingSphere, Zipkin
> >
> >
> >
> > > 在 2019年6月17日，下午5:57，Christofer Dutz  写道：
> > >
> > > But if you are releasing Maven artifacts, I would assume that you
> change the group-ids to not start with "org.apache"
> > > and the packages should probably be changed too. But not 100% sure if
> this is just a nice-to-have or a hard requirement.
> > > And also I didn't check the coordinates or package structure of the
> repo ... so just ignore me, if this all doesn't apply ;-)
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 17.06.19, 11:52 schrieb "Sheng Wu" :
> > >
> > >Hi Incubator.
> > >
> > >As a Zipkin incubator mentor, I am asking to make Zipkin all
> repositories back to original OpenZipkin org as soon as possible.
> > >
> > >They have done a public ml vote, result is here[1].
> > >Also, with no transfer happened about Zipkin trademark, logo,
> domain, so, there is no such thing about return the trademark or permission
> of using Zipkin name.
> > >
> > >Zipkin is a big community and a lots of dependency out there are
> waiting for release.
> > >
> > >I think there is nothing hold this transfer, right?
> > >If so, please give a clear reply. The INFRA team is waiting at this
> JIRA ticket[2].
> > >
> > >
> > >[1]
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> <
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> >
> > >[2] https://issues.apache.org/jira/browse/INFRA-18604 <
> https://issues.apache.org/jira/browse/INFRA-18604>
> > >
> > >
> > >Sheng Wu
> > >Apache Skywalking, ShardingSphere, Zipkin
> > >
> > >
> > >
> > >
> > >
> > >
> > > -
> > > 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
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread John D. Ament 
+1 these seem to make the most sense to me

On Mon, Jun 17, 2019, 16:29 Dave Fisher  wrote:

> Hi -
>
> A retirement VOTE on general@ is required. [1] This is the last formality
> required. Incubation is not for every project.
>
> Then follow [2] as much as possible, but with the exception of
> transferring the repositories back to OpenZipken. In addition the IPMC will
> request that INFRA make read-only RETIRED clones of each repository.
>
> Regards,
> Dave
>
> [1] https://incubator.apache.org/guides/retirement.html#deciding_to_retire
> [2]
> https://incubator.apache.org/guides/retirement.html#steps_to_retirement
>
> > On Jun 17, 2019, at 2:52 AM, Sheng Wu  wrote:
> >
> > Hi Incubator.
> >
> > As a Zipkin incubator mentor, I am asking to make Zipkin all
> repositories back to original OpenZipkin org as soon as possible.
> >
> > They have done a public ml vote, result is here[1].
> > Also, with no transfer happened about Zipkin trademark, logo, domain,
> so, there is no such thing about return the trademark or permission of
> using Zipkin name.
> >
> > Zipkin is a big community and a lots of dependency out there are waiting
> for release.
> >
> > I think there is nothing hold this transfer, right?
> > If so, please give a clear reply. The INFRA team is waiting at this JIRA
> ticket[2].
> >
> >
> > [1]
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> <
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> >
> > [2] https://issues.apache.org/jira/browse/INFRA-18604 <
> https://issues.apache.org/jira/browse/INFRA-18604>
> >
> >
> > Sheng Wu
> > Apache Skywalking, ShardingSphere, Zipkin
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Dave Fisher 
Hi -

A retirement VOTE on general@ is required. [1] This is the last formality 
required. Incubation is not for every project.

Then follow [2] as much as possible, but with the exception of transferring the 
repositories back to OpenZipken. In addition the IPMC will request that INFRA 
make read-only RETIRED clones of each repository. 

Regards,
Dave

[1] https://incubator.apache.org/guides/retirement.html#deciding_to_retire
[2] https://incubator.apache.org/guides/retirement.html#steps_to_retirement

> On Jun 17, 2019, at 2:52 AM, Sheng Wu  wrote:
> 
> Hi Incubator.
> 
> As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
> back to original OpenZipkin org as soon as possible.
> 
> They have done a public ml vote, result is here[1].
> Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
> there is no such thing about return the trademark or permission of using 
> Zipkin name.
> 
> Zipkin is a big community and a lots of dependency out there are waiting for 
> release.
> 
> I think there is nothing hold this transfer, right?
> If so, please give a clear reply. The INFRA team is waiting at this JIRA 
> ticket[2].
> 
> 
> [1] 
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
>  
> 
> [2] https://issues.apache.org/jira/browse/INFRA-18604 
> 
> 
> 
> Sheng Wu
> Apache Skywalking, ShardingSphere, Zipkin
> 
> 
> 


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

Re: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread sebb 
I agree it's not a block, but there is scope for some classpath confusion.

If someone has an app that includes both the ASF and non-ASF Zipkin
jars, both will end up on the Maven classpath.
There is no way to tell which version of a particular class will end
up being loaded.

A Maven relocation pom might help to ensure that only one version of
the jars ends up on the Maven classpath, but I've not tried that.

The recommended procedure is to always ensure that there is a 1:1
relationship between Maven coords and Java package name.
There can then be no chance of incompatible jars on the classpath.

On Mon, 17 Jun 2019 at 14:17, Sheng Wu  wrote:
>
> Hi
> Zipkin doesn’t change the java package name, and had no plan to do that.
> We just changed the groupid, and are reverting it back to `io.zipkin`.
>
> So, I don’t see this as a block.
>
> Sheng Wu
> Apache Skywalking, ShardingSphere, Zipkin
>
>
>
> > 在 2019年6月17日，下午5:57，Christofer Dutz  写道：
> >
> > But if you are releasing Maven artifacts, I would assume that you change 
> > the group-ids to not start with "org.apache"
> > and the packages should probably be changed too. But not 100% sure if this 
> > is just a nice-to-have or a hard requirement.
> > And also I didn't check the coordinates or package structure of the repo 
> > ... so just ignore me, if this all doesn't apply ;-)
> >
> > Chris
> >
> >
> >
> > Am 17.06.19, 11:52 schrieb "Sheng Wu" :
> >
> >Hi Incubator.
> >
> >As a Zipkin incubator mentor, I am asking to make Zipkin all 
> > repositories back to original OpenZipkin org as soon as possible.
> >
> >They have done a public ml vote, result is here[1].
> >Also, with no transfer happened about Zipkin trademark, logo, domain, 
> > so, there is no such thing about return the trademark or permission of 
> > using Zipkin name.
> >
> >Zipkin is a big community and a lots of dependency out there are waiting 
> > for release.
> >
> >I think there is nothing hold this transfer, right?
> >If so, please give a clear reply. The INFRA team is waiting at this JIRA 
> > ticket[2].
> >
> >
> >[1] 
> > https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
> >  
> > 
> >[2] https://issues.apache.org/jira/browse/INFRA-18604 
> > 
> >
> >
> >Sheng Wu
> >Apache Skywalking, ShardingSphere, Zipkin
> >
> >
> >
> >
> >
> >
> > -
> > 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
>

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

Re: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread David Nalley 
On Mon, Jun 17, 2019 at 5:58 AM Christofer Dutz
 wrote:
>
> But if you are releasing Maven artifacts, I would assume that you change the 
> group-ids to not start with "org.apache"
> and the packages should probably be changed too. But not 100% sure if this is 
> just a nice-to-have or a hard requirement.
> And also I didn't check the coordinates or package structure of the repo ... 
> so just ignore me, if this all doesn't apply ;-)
>

It's a non-issue. The org.apache coordinates are relatively tightly
locked down in Central.

--David

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

Re: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Sheng Wu 
Hi
Zipkin doesn’t change the java package name, and had no plan to do that.
We just changed the groupid, and are reverting it back to `io.zipkin`.

So, I don’t see this as a block.

Sheng Wu
Apache Skywalking, ShardingSphere, Zipkin



> 在 2019年6月17日，下午5:57，Christofer Dutz  写道：
> 
> But if you are releasing Maven artifacts, I would assume that you change the 
> group-ids to not start with "org.apache" 
> and the packages should probably be changed too. But not 100% sure if this is 
> just a nice-to-have or a hard requirement.
> And also I didn't check the coordinates or package structure of the repo ... 
> so just ignore me, if this all doesn't apply ;-)
> 
> Chris
> 
> 
> 
> Am 17.06.19, 11:52 schrieb "Sheng Wu" :
> 
>Hi Incubator.
> 
>As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
> back to original OpenZipkin org as soon as possible.
> 
>They have done a public ml vote, result is here[1].
>Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
> there is no such thing about return the trademark or permission of using 
> Zipkin name.
> 
>Zipkin is a big community and a lots of dependency out there are waiting 
> for release.
> 
>I think there is nothing hold this transfer, right?
>If so, please give a clear reply. The INFRA team is waiting at this JIRA 
> ticket[2].
> 
> 
>[1] 
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
>  
> 
>[2] https://issues.apache.org/jira/browse/INFRA-18604 
> 
> 
> 
>Sheng Wu
>Apache Skywalking, ShardingSphere, Zipkin
> 
> 
> 
> 
> 
> 
> -
> 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: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Adrian Cole 
as there was little progress inside incubator, the far easiest on
everyone is to resume our old "io.zipkin" group ids. We have no plans
to use any apache namespaces as it represents one release of several
out of many projects. Least surprising and distracting is a
straightforward revert.

-A

On Mon, Jun 17, 2019 at 5:57 PM Christofer Dutz
 wrote:
>
> But if you are releasing Maven artifacts, I would assume that you change the 
> group-ids to not start with "org.apache"
> and the packages should probably be changed too. But not 100% sure if this is 
> just a nice-to-have or a hard requirement.
> And also I didn't check the coordinates or package structure of the repo ... 
> so just ignore me, if this all doesn't apply ;-)
>
> Chris
>
>
>
> Am 17.06.19, 11:52 schrieb "Sheng Wu" :
>
> Hi Incubator.
>
> As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
> back to original OpenZipkin org as soon as possible.
>
> They have done a public ml vote, result is here[1].
> Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
> there is no such thing about return the trademark or permission of using 
> Zipkin name.
>
> Zipkin is a big community and a lots of dependency out there are waiting 
> for release.
>
> I think there is nothing hold this transfer, right?
> If so, please give a clear reply. The INFRA team is waiting at this JIRA 
> ticket[2].
>
>
> [1] 
> https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
>  
> 
> [2] https://issues.apache.org/jira/browse/INFRA-18604 
> 
>
>
> Sheng Wu
> Apache Skywalking, ShardingSphere, Zipkin
>
>
>
>
>
>
> -
> 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: Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Christofer Dutz 
But if you are releasing Maven artifacts, I would assume that you change the 
group-ids to not start with "org.apache" 
and the packages should probably be changed too. But not 100% sure if this is 
just a nice-to-have or a hard requirement.
And also I didn't check the coordinates or package structure of the repo ... so 
just ignore me, if this all doesn't apply ;-)

Chris



Am 17.06.19, 11:52 schrieb "Sheng Wu" :

Hi Incubator.

As a Zipkin incubator mentor, I am asking to make Zipkin all repositories 
back to original OpenZipkin org as soon as possible.

They have done a public ml vote, result is here[1].
Also, with no transfer happened about Zipkin trademark, logo, domain, so, 
there is no such thing about return the trademark or permission of using Zipkin 
name.

Zipkin is a big community and a lots of dependency out there are waiting 
for release.

I think there is nothing hold this transfer, right?
If so, please give a clear reply. The INFRA team is waiting at this JIRA 
ticket[2].


[1] 
https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
 

[2] https://issues.apache.org/jira/browse/INFRA-18604 



Sheng Wu
Apache Skywalking, ShardingSphere, Zipkin






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

Move the Zipkin repos back, as the community has voted to leave.

2019-06-17 Thread Sheng Wu 
Hi Incubator.

As a Zipkin incubator mentor, I am asking to make Zipkin all repositories back 
to original OpenZipkin org as soon as possible.

They have done a public ml vote, result is here[1].
Also, with no transfer happened about Zipkin trademark, logo, domain, so, there 
is no such thing about return the trademark or permission of using Zipkin name.

Zipkin is a big community and a lots of dependency out there are waiting for 
release.

I think there is nothing hold this transfer, right?
If so, please give a clear reply. The INFRA team is waiting at this JIRA 
ticket[2].


[1] 
https://lists.apache.org/thread.html/fbeb254f569d9852e9740d55532ee338580287ec384e26c7d9107964@%3Cdev.zipkin.apache.org%3E
 

[2] https://issues.apache.org/jira/browse/INFRA-18604 



Sheng Wu
Apache Skywalking, ShardingSphere, Zipkin