Re: Unapproved Sharding Sphere releases

[Craig Russell]

If we agree that new incubating projects have their repositories moved and not 
copied, I think it is only fair that the projects also can choose when the 
transition from "outside project" to "incubating project" occur with regard to 
releases.

I do not think it is fair to require a community coming into incubation to have 
finished all "outside project" work prior to having the vote to join the 
incubator, and to remove all releases made outside.

What I recommended to the ShardingSphere community was to delay moving the 
repository until after their final "outside project" release. Then there would 
be a definite transition point from "outside project" to "incubating project".

As the first step after the repository is moved to Apache infrastructure, the 
previous releases can be labeled "Not Apache Release" but I do not feel that it 
is fair to remove them.

Craig
Mentor, ShardingSphere

> On Feb 8, 2019, at 3:52 PM, 吴晟 Sheng Wu  wrote:
> 
> I support move than copy too. 
> Move is better, not just for keeping star, fork and watch. These are also 
> important too.
> The more important is, GitHub provides repo address auto redirect. If the 
> user or article links to the old repo, it will forward to the new one(Apache 
> one) automatically. 
> 
> 
> 
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
> 
> From Wu Sheng 's phone.
> 
> 
> -- Original ------
> From: Chris Lambertus 
> Date: Sat,Feb 9,2019 4:34 AM
> To: general 
> Cc: dev 
> Subject: Re: Unapproved Sharding Sphere releases
> 
> 
> 
> 
> 
>> On Feb 7, 2019, at 1:52 PM, Dave Fisher  wrote:
>> 
>> 
>> 
>>> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:
> 
> [snip]
> 
>>> 
>>> Larger discussion: Is there a reason for projects coming into incubation to 
>>> have the old repository moved (i.e. renamed) instead of being copied? I 
>>> cannot think of a good use case for moving versus copying. Seems like any 
>>> project that had releases and a community outside Apache would want to 
>>> copy, not move.
>> 
>> If the project is moved then all of the thousands of forks and stars are 
>> still associated with the original project. If copied then all of these will 
>> be associated with the now abandoned repository and most of those will never 
>> come along with the moving project.
>> 
>> For the Chinese projects this can mean losing thousands of users and 
>> sometime contributors to the project.
>> 
>> So, I am a MOVE and not COPY.
>> 
>> ShardingSphere has 6,633 stars and 2,363 forks plus 842 watches.
>> 
>>> 
>>> Smaller discussion: Should the JIRA have been written to request 
>>> copying/forking the project? Or is this something that is supposed to be 
>>> self-serve. I could not find a definitive answer to this.
>> 
>> Ask Infra. ASICT they move by default.
> 
> 
> We endeavor to perform move operations wherever technically possible for the 
> exact reason of retaining the stars and other metadata associated with the 
> github project. It adds a few extra steps for us, but the projects always 
> appreciate having that data retained. If we did a “copy” then there would be 
> two extant repos which would cause no end of confusion, especially for people 
> with forks and watches on the original repo.
> 
> -Chris
> ASF Infra

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
<http://db.apache.org/jdo>

Re: Unapproved Sharding Sphere releases

[???? Sheng Wu]

I support move than copy too. 
Move is better, not just for keeping star, fork and watch. These are also 
important too.
The more important is, GitHub provides repo address auto redirect. If the user 
or article links to the old repo, it will forward to the new one(Apache one) 
automatically. 



Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: Chris Lambertus 
Date: Sat,Feb 9,2019 4:34 AM
To: general 
Cc: dev 
Subject: Re: Unapproved Sharding Sphere releases





> On Feb 7, 2019, at 1:52 PM, Dave Fisher  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:

[snip]

>> 
>> Larger discussion: Is there a reason for projects coming into incubation to 
>> have the old repository moved (i.e. renamed) instead of being copied? I 
>> cannot think of a good use case for moving versus copying. Seems like any 
>> project that had releases and a community outside Apache would want to copy, 
>> not move.
> 
> If the project is moved then all of the thousands of forks and stars are 
> still associated with the original project. If copied then all of these will 
> be associated with the now abandoned repository and most of those will never 
> come along with the moving project.
> 
> For the Chinese projects this can mean losing thousands of users and sometime 
> contributors to the project.
> 
> So, I am a MOVE and not COPY.
> 
> ShardingSphere has 6,633 stars and 2,363 forks plus 842 watches.
> 
>> 
>> Smaller discussion: Should the JIRA have been written to request 
>> copying/forking the project? Or is this something that is supposed to be 
>> self-serve. I could not find a definitive answer to this.
> 
> Ask Infra. ASICT they move by default.


We endeavor to perform move operations wherever technically possible for the 
exact reason of retaining the stars and other metadata associated with the 
github project. It adds a few extra steps for us, but the projects always 
appreciate having that data retained. If we did a ??copy?? then there would be 
two extant repos which would cause no end of confusion, especially for people 
with forks and watches on the original repo.

-Chris
ASF Infra

Re: Unapproved Sharding Sphere releases

[Chris Lambertus]

> On Feb 7, 2019, at 1:52 PM, Dave Fisher  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:

[snip]

>> 
>> Larger discussion: Is there a reason for projects coming into incubation to 
>> have the old repository moved (i.e. renamed) instead of being copied? I 
>> cannot think of a good use case for moving versus copying. Seems like any 
>> project that had releases and a community outside Apache would want to copy, 
>> not move.
> 
> If the project is moved then all of the thousands of forks and stars are 
> still associated with the original project. If copied then all of these will 
> be associated with the now abandoned repository and most of those will never 
> come along with the moving project.
> 
> For the Chinese projects this can mean losing thousands of users and sometime 
> contributors to the project.
> 
> So, I am a MOVE and not COPY.
> 
> ShardingSphere has 6,633 stars and 2,363 forks plus 842 watches.
> 
>> 
>> Smaller discussion: Should the JIRA have been written to request 
>> copying/forking the project? Or is this something that is supposed to be 
>> self-serve. I could not find a definitive answer to this.
> 
> Ask Infra. ASICT they move by default.


We endeavor to perform move operations wherever technically possible for the 
exact reason of retaining the stars and other metadata associated with the 
github project. It adds a few extra steps for us, but the projects always 
appreciate having that data retained. If we did a “copy” then there would be 
two extant repos which would cause no end of confusion, especially for people 
with forks and watches on the original repo.

-Chris
ASF Infra

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 1:55 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Do we recommend that the Title be changed to add “Non-Apache release from 
>> prior to Incubation” or would it be sufficient for that text to be added to 
>> the Description?
> 
> IMO however the PPMC want to handle it as long as it’s clear it’s not an 
> Apache release and came before the incubation date. I’ve given such advice to 
> several incubating projects. e.g. [1]

Appending “  (non-apache release)” or “ (pre-apache release)” to the title is a 
reasonable recommendation for current and future podlings.

Also the pre-release checkbox and draft tags may also be used.

Regards,
Dave

> 
> Thanks,
> Justin
> 
> 1. https://github.com/apache/incubator-doris/releases
> -
> 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: Unapproved Sharding Sphere releases

[Justin Mclean]

Hi,

> Do we recommend that the Title be changed to add “Non-Apache release from 
> prior to Incubation” or would it be sufficient for that text to be added to 
> the Description?

IMO however the PPMC want to handle it as long as it’s clear it’s not an Apache 
release and came before the incubation date. I’ve given such advice to several 
incubating projects. e.g. [1]

Thanks,
Justin

1. https://github.com/apache/incubator-doris/releases
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 1:44 PM, Craig Russell  wrote:
> 
>> On Feb 7, 2019, at 11:02 AM, Dave Fisher  wrote:
>> 
>>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 
>>>  
>> 
>> The old repository was moved to the ASF and logically that should also have 
>> moved the legacy releases.
> 
> Doh! I learn something new about git every day. My assumption all along was 
> that the contents of the repository were to be copied, leaving the old 
> repository/web-pages/releases intact.
> 
> Larger discussion: Is there a reason for projects coming into incubation to 
> have the old repository moved (i.e. renamed) instead of being copied? I 
> cannot think of a good use case for moving versus copying. Seems like any 
> project that had releases and a community outside Apache would want to copy, 
> not move.

If the project is moved then all of the thousands of forks and stars are still 
associated with the original project. If copied then all of these will be 
associated with the now abandoned repository and most of those will never come 
along with the moving project.

For the Chinese projects this can mean losing thousands of users and sometime 
contributors to the project.

So, I am a MOVE and not COPY.

ShardingSphere has 6,633 stars and 2,363 forks plus 842 watches.

> 
> Smaller discussion: Should the JIRA have been written to request 
> copying/forking the project? Or is this something that is supposed to be 
> self-serve. I could not find a definitive answer to this.

Ask Infra. ASICT they move by default.

Regards,
Dave


> 
> Craig
>> 
>> There are tradeoffs between moving / renaming and cloning. What moving the 
>> repository means is that technically there is no old repository or project.
>> 
>> Prior “Non-Apache Releases” are attached to the repository and come along. 
>> What to do? I think we have to accept these, but mark them appropriately as 
>> deleting them would be for the project community during transition.
>> 
>> Regards,
>> Dave
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo 
> 


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

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 1:24 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Prior “Non-Apache Releases” are attached to the repository and come along. 
>> What to do? I think we have to accept these, but mark them appropriately as 
>> deleting them would be for the project community during transition.
> 
> +1 Clearly labelling any non-apache releases prior to the the data of 
> incubation is fine. It makes it clear that they were not made while the 
> project was at the ASF.

Since we are working to inform podlings how to fix an oversight I think we 
should be prescriptive.

To fix this the PPMC would go to each pre-Apache release and edit the release: 
https://help.github.com/articles/editing-and-deleting-releases/ 


Do we recommend that the Title be changed to add “Non-Apache release from prior 
to Incubation” or would it be sufficient for that text to be added to the 
Description?

Thanks,
Dave

> 
> Thanks,
> Justin

Re: Unapproved Sharding Sphere releases

[Craig Russell]

> On Feb 7, 2019, at 11:02 AM, Dave Fisher  wrote:
> 
>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 
>>  
> 
> The old repository was moved to the ASF and logically that should also have 
> moved the legacy releases.

Doh! I learn something new about git every day. My assumption all along was 
that the contents of the repository were to be copied, leaving the old 
repository/web-pages/releases intact.

Larger discussion: Is there a reason for projects coming into incubation to 
have the old repository moved (i.e. renamed) instead of being copied? I cannot 
think of a good use case for moving versus copying. Seems like any project that 
had releases and a community outside Apache would want to copy, not move.

Smaller discussion: Should the JIRA have been written to request 
copying/forking the project? Or is this something that is supposed to be 
self-serve. I could not find a definitive answer to this.

Craig
> 
> There are tradeoffs between moving / renaming and cloning. What moving the 
> repository means is that technically there is no old repository or project.
> 
> Prior “Non-Apache Releases” are attached to the repository and come along. 
> What to do? I think we have to accept these, but mark them appropriately as 
> deleting them would be for the project community during transition.
> 
> Regards,
> Dave

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Unapproved Sharding Sphere releases

[Justin Mclean]

Hi,

> Prior “Non-Apache Releases” are attached to the repository and come along. 
> What to do? I think we have to accept these, but mark them appropriately as 
> deleting them would be for the project community during transition.

+1 Clearly labelling any non-apache releases prior to the the data of 
incubation is fine. It makes it clear that they were not made while the project 
was at the ASF.

Thanks,
Justin

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 10:46 AM, Craig Russell  wrote:
> 
> Hi Dave,
> 
>> On Feb 7, 2019, at 9:12 AM, Dave Fisher  wrote:
>> 
>> 
>> 
>>> On Feb 7, 2019, at 8:31 AM, Craig Russell  wrote:
>>> 
>>> 
>>> 
 On Feb 6, 2019, at 10:31 PM, Justin Mclean  
 wrote:
 
 HI,
 
> This was done. The issue is that the "3.0.0 outside Apache" release 
> should not be associated with Apache but with the previous project.
 
 They also made a 3.1.0 release as well and it was on the Apache github 
 site (both 3.0 and 3.1 have now been removed from there).
 
> It looks like the original repositories have been changed to redirect to 
> Apache. I'd suggest restoring the original 
> https://github.com/sharding-sphere/ 
> * repositories so 
> they don't automatically redirect to the Apache podling git repositories. 
 
 I’m not so sure that's OK. It’s probably not right for a PPMC to be 
 releasing software anywhere advertised to the general public that hasn’t 
 been approved for release. Could a 3rd party do it sure, could they call 
 it Sharding Sphere probably not.
>>> 
>>> To be clear, the ShardingSphere PPMC did not release anything. The group of 
>>> people who managed the project before it became the ShardingSphere PPMC did 
>>> the release.
>>> 
>>> The unfortunate thing is that the ShardingSphere PPMC then made the release 
>>> available on the PPMC-managed site. This is the wrong thing that needs to 
>>> be fixed. Removing the 3.x releases from the Apache site is part of the 
>>> fix. Restoring the github project that existed prior to the creation of the 
>>> podling is the other part.
>>> 
>>> I hope we can agree that there are two separate projects. One of them will 
>>> be obsolete and will disappear once Apache ShardingSphere graduates. The 
>>> old ShardingSphere will no longer have rights to the name. 
>> 
>> Was the ASF Git for ShardingSphere created by cloning the legacy project, or 
>> was the repo transferred under an SGA?
>> 
> I believe this INFRA ticket has the relevant information: 
> 
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 
> 

The old repository was moved to the ASF and logically that should also have 
moved the legacy releases.

There are tradeoffs between moving / renaming and cloning. What moving the 
repository means is that technically there is no old repository or project.

Prior “Non-Apache Releases” are attached to the repository and come along. What 
to do? I think we have to accept these, but mark them appropriately as deleting 
them would be for the project community during transition.

Regards,
Dave

> 
> More details on provenance:
> 
> https://wiki.apache.org/incubator/ShardingSphereProposal
> 
> The code base was granted by Dangdang:
> 
> https://svn.apache.org/repos/private/documents/grants/dangdang-sharding-sphere.pdf
> 
> Craig
> 
>> Regards,
>> Dave
>> 
>>> 
>>> Regards,
>>> 
>>> Craig
 
 Thanks,
 Justin
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
 
 For additional commands, e-mail: general-h...@incubator.apache.org 
 
 
>>> 
>>> Craig L Russell
>>> c...@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 
>> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org  http://db.apache.org/jdo 
> 

Re: Unapproved Sharding Sphere releases

[Craig Russell]

Hi Dave,

> On Feb 7, 2019, at 9:12 AM, Dave Fisher  wrote:
> 
> 
> 
>> On Feb 7, 2019, at 8:31 AM, Craig Russell  wrote:
>> 
>> 
>> 
>>> On Feb 6, 2019, at 10:31 PM, Justin Mclean  wrote:
>>> 
>>> HI,
>>> 
 This was done. The issue is that the "3.0.0 outside Apache" release should 
 not be associated with Apache but with the previous project.
>>> 
>>> They also made a 3.1.0 release as well and it was on the Apache github site 
>>> (both 3.0 and 3.1 have now been removed from there).
>>> 
 It looks like the original repositories have been changed to redirect to 
 Apache. I'd suggest restoring the original 
 https://github.com/sharding-sphere/ 
 * repositories so 
 they don't automatically redirect to the Apache podling git repositories. 
>>> 
>>> I’m not so sure that's OK. It’s probably not right for a PPMC to be 
>>> releasing software anywhere advertised to the general public that hasn’t 
>>> been approved for release. Could a 3rd party do it sure, could they call it 
>>> Sharding Sphere probably not.
>> 
>> To be clear, the ShardingSphere PPMC did not release anything. The group of 
>> people who managed the project before it became the ShardingSphere PPMC did 
>> the release.
>> 
>> The unfortunate thing is that the ShardingSphere PPMC then made the release 
>> available on the PPMC-managed site. This is the wrong thing that needs to be 
>> fixed. Removing the 3.x releases from the Apache site is part of the fix. 
>> Restoring the github project that existed prior to the creation of the 
>> podling is the other part.
>> 
>> I hope we can agree that there are two separate projects. One of them will 
>> be obsolete and will disappear once Apache ShardingSphere graduates. The old 
>> ShardingSphere will no longer have rights to the name. 
> 
> Was the ASF Git for ShardingSphere created by cloning the legacy project, or 
> was the repo transferred under an SGA?
> 
I believe this INFRA ticket has the relevant information: 

https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289

More details on provenance:

https://wiki.apache.org/incubator/ShardingSphereProposal

The code base was granted by Dangdang:

https://svn.apache.org/repos/private/documents/grants/dangdang-sharding-sphere.pdf

Craig

> Regards,
> Dave
> 
>> 
>> Regards,
>> 
>> Craig
>>> 
>>> Thanks,
>>> Justin
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
>>> 
>>> For additional commands, e-mail: general-h...@incubator.apache.org 
>>> 
>>> 
>> 
>> Craig L Russell
>> c...@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 
> 
Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Unapproved Sharding Sphere releases

[Dave Fisher]

> On Feb 7, 2019, at 8:31 AM, Craig Russell  wrote:
> 
> 
> 
>> On Feb 6, 2019, at 10:31 PM, Justin Mclean  wrote:
>> 
>> HI,
>> 
>>> This was done. The issue is that the "3.0.0 outside Apache" release should 
>>> not be associated with Apache but with the previous project.
>> 
>> They also made a 3.1.0 release as well and it was on the Apache github site 
>> (both 3.0 and 3.1 have now been removed from there).
>> 
>>> It looks like the original repositories have been changed to redirect to 
>>> Apache. I'd suggest restoring the original 
>>> https://github.com/sharding-sphere/ 
>>> * repositories so 
>>> they don't automatically redirect to the Apache podling git repositories. 
>> 
>> I’m not so sure that's OK. It’s probably not right for a PPMC to be 
>> releasing software anywhere advertised to the general public that hasn’t 
>> been approved for release. Could a 3rd party do it sure, could they call it 
>> Sharding Sphere probably not.
> 
> To be clear, the ShardingSphere PPMC did not release anything. The group of 
> people who managed the project before it became the ShardingSphere PPMC did 
> the release.
> 
> The unfortunate thing is that the ShardingSphere PPMC then made the release 
> available on the PPMC-managed site. This is the wrong thing that needs to be 
> fixed. Removing the 3.x releases from the Apache site is part of the fix. 
> Restoring the github project that existed prior to the creation of the 
> podling is the other part.
> 
> I hope we can agree that there are two separate projects. One of them will be 
> obsolete and will disappear once Apache ShardingSphere graduates. The old 
> ShardingSphere will no longer have rights to the name. 

Was the ASF Git for ShardingSphere created by cloning the legacy project, or 
was the repo transferred under an SGA?

Regards,
Dave

> 
> Regards,
> 
> Craig
>> 
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> Craig L Russell
> c...@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: Unapproved Sharding Sphere releases

[Craig Russell]

> On Feb 6, 2019, at 10:31 PM, Justin Mclean  wrote:
> 
> HI,
> 
>> This was done. The issue is that the "3.0.0 outside Apache" release should 
>> not be associated with Apache but with the previous project.
> 
> They also made a 3.1.0 release as well and it was on the Apache github site 
> (both 3.0 and 3.1 have now been removed from there).
> 
>> It looks like the original repositories have been changed to redirect to 
>> Apache. I'd suggest restoring the original 
>> https://github.com/sharding-sphere/ 
>> * repositories so 
>> they don't automatically redirect to the Apache podling git repositories. 
> 
> I’m not so sure that's OK. It’s probably not right for a PPMC to be releasing 
> software anywhere advertised to the general public that hasn’t been approved 
> for release. Could a 3rd party do it sure, could they call it Sharding Sphere 
> probably not.

To be clear, the ShardingSphere PPMC did not release anything. The group of 
people who managed the project before it became the ShardingSphere PPMC did the 
release.

The unfortunate thing is that the ShardingSphere PPMC then made the release 
available on the PPMC-managed site. This is the wrong thing that needs to be 
fixed. Removing the 3.x releases from the Apache site is part of the fix. 
Restoring the github project that existed prior to the creation of the podling 
is the other part.

I hope we can agree that there are two separate projects. One of them will be 
obsolete and will disappear once Apache ShardingSphere graduates. The old 
ShardingSphere will no longer have rights to the name. 

Regards,

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

Craig L Russell
c...@apache.org


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

Re: Unapproved Sharding Sphere releases

[Justin Mclean]

HI,

> This was done. The issue is that the "3.0.0 outside Apache" release should 
> not be associated with Apache but with the previous project.

They also made a 3.1.0 release as well and it was on the Apache github site 
(both 3.0 and 3.1 have now been removed from there).

> It looks like the original repositories have been changed to redirect to 
> Apache. I'd suggest restoring the original 
> https://github.com/sharding-sphere/ 
> * repositories so 
> they don't automatically redirect to the Apache podling git repositories. 

I’m not so sure that's OK. It’s probably not right for a PPMC to be releasing 
software anywhere advertised to the general public that hasn’t been approved 
for release. Could a 3rd party do it sure, could they call it Sharding Sphere 
probably not.

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

Re: Unapproved Sharding Sphere releases

[Craig Russell]

Sorry I have not been following this as closely as I should have.

It was decided after ShardingSphere was accepted into the incubator that the 
project would make a final release outside the incubator and then bring the 
code into Apache. The release 4.0.0 would be an Apache release.

This was done. The issue is that the "3.0.0 outside Apache" release should not 
be associated with Apache but with the previous project.

So, there are not yet any Apache ShardingSphere releases. But there is no 
reason to disallow the 3.0.0 release to be published from its previous home.

It looks like the original repositories have been changed to redirect to 
Apache. I'd suggest restoring the original https://github.com/sharding-sphere/ 
<https://github.com/sharding-sphere/sharding-sphere.git>* repositories so they 
don't automatically redirect to the Apache podling git repositories. 

There are two projects now and they should remain separate. At some point, 
people will migrate from the previous project to Apache. But that time has not 
come.

WDYT?

Craig


> On Feb 1, 2019, at 6:56 AM, zhangli...@apache.org wrote:
> 
> I updated wiki for remove unapproved releases.
> 
> --
> 
> Liang Zhang (John)
> Apache ShardingSphere & Dubbo
> 
> 
> 吴晟 Sheng Wu  于2019年2月1日周五 下午10:51写道：
> 
>> Hi
>> 
>> 
>> By following the Apache policy, besides the suggestions I gave and done.
>> Just a moment ago, I deleted the recent two unapproved releases, 3.1.0.m1
>> and 3.1.0 at GitHub release page[1].
>> 
>> 
>> In further, I will help the shardingsphere community to follow the policy.
>> 
>> 
>> 
>> 
>> [1] https://github.com/apache/incubator-shardingsphere/releases
>> 
>> Sheng Wu
>> Apache SkyWalking, ShardingSphere, Zipkin
>> 
>> From Wu Sheng 's phone.
>> 
>> 
>> -- Original ----------
>> From: 吴晟 Sheng Wu 
>> Date: Wed,Jan 30,2019 5:54 PM
>> To: dev , dev <
>> d...@shardingsphere.apache.org>
>> Cc: Justin Mclean , jmclean 
>> Subject: Re: Unapproved Sharding Sphere releases
>> 
>> 
>> 
>> Hi
>> 
>> 
>> I think I agree the Justin's points.
>> No matter the release happens in Apache org repo or not, it still happened
>> after you asked and accepted by Incubator. So, it is not encouraged and not
>> following the Apache way.
>> 
>> 
>> I propose these adjustments
>> 1. Add statement in GitHub release versions. Saying these are not Apache
>> release.
>> 2. Add statement in you website home, document and download pages, saying
>> all available releases are not Apache releases
>> 3. After the first approved release, you only says before this
>> version(4.0.0 maybe) are not Apachre releases.
>> 4. Add statement in GitHub project readme.md for the same thing.
>> 
>> 
>> Especially for document pages, this needs to be tagged in clear way.
>> I know, those releases in maven central repo are hard to release, and not
>> good for the existing community. So, I hope my proposals are good enough.
>> 
>> 
>> 
>> Sheng Wu
>> Apache SkyWalking, ShardingSphere, Zipkin
>> 
>> From Wu Sheng 's phone.
>> 
>> 
>> -- Original --
>> From: zhangli...@apache.org 
>> Date: Wed,Jan 30,2019 0:03 PM
>> To: dev 
>> Cc: Justin Mclean , jmclean 
>> Subject: Re: Unapproved Sharding Sphere releases
>> 
>> 
>> 
>> Hello Justin,
>> 
>> Thanks for your advice.
>> This is a legacy release, which we have discussed on the dev mail list[1]
>> before.
>> This release is done before the transfer to ASF repo and package rename.
>> We are now preparing apache release which begins with new version(4.0.0).
>> We will not release non-Apache version any more in the future.
>> Any suggestion to identify versions like these kind of releases?
>> 
>> 
>> [1]
>> 
>> https://lists.apache.org/thread.html/a3bba7e53bfed6d18924b592ecf0533aebc8d307f8c7e399a7fec2cf@%3Cdev.shardingsphere.apache.org%3E
>> 
>> --
>> 
>> Liang Zhang (John)
>> Apache ShardingSphere & Dubbo
>> 
>> 
>> Justin Mclean  于2019年1月30日周三 上午6:23写道：
>> 
>>> Hi,
>>> 
>>> Looking at [1] there seems to have been releases made after you have
>>> entered incubation. All releases must be approved by the PPMC and the
>> IPMC
>>> (usually by voting). Can you please remove these releases and include in
>>> your upcoming incubator report what you will do to stop this happening
>>> going forward.
>>> 
>>> Thanks,
>>> Justin
>>> 
>>> P.S please CC me on any replies as I'm not subscribed to this list
>>> 
>>> 1.https://github.com/apache/incubator-shardingsphere/releases
>>> 
>>> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
<http://db.apache.org/jdo>

Re: Unapproved Sharding Sphere releases

[zhangli...@apache.org]

I updated wiki for remove unapproved releases.

--

Liang Zhang (John)
Apache ShardingSphere & Dubbo


吴晟 Sheng Wu  于2019年2月1日周五 下午10:51写道：

> Hi
>
>
> By following the Apache policy, besides the suggestions I gave and done.
> Just a moment ago, I deleted the recent two unapproved releases, 3.1.0.m1
> and 3.1.0 at GitHub release page[1].
>
>
> In further, I will help the shardingsphere community to follow the policy.
>
>
>
>
> [1] https://github.com/apache/incubator-shardingsphere/releases
>
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
>
> From Wu Sheng 's phone.
>
>
> -- Original --
> From: 吴晟 Sheng Wu 
> Date: Wed,Jan 30,2019 5:54 PM
> To: dev , dev <
> d...@shardingsphere.apache.org>
> Cc: Justin Mclean , jmclean 
> Subject: Re: Unapproved Sharding Sphere releases
>
>
>
> Hi
>
>
> I think I agree the Justin's points.
> No matter the release happens in Apache org repo or not, it still happened
> after you asked and accepted by Incubator. So, it is not encouraged and not
> following the Apache way.
>
>
> I propose these adjustments
> 1. Add statement in GitHub release versions. Saying these are not Apache
> release.
> 2. Add statement in you website home, document and download pages, saying
> all available releases are not Apache releases
> 3. After the first approved release, you only says before this
> version(4.0.0 maybe) are not Apachre releases.
> 4. Add statement in GitHub project readme.md for the same thing.
>
>
> Especially for document pages, this needs to be tagged in clear way.
> I know, those releases in maven central repo are hard to release, and not
> good for the existing community. So, I hope my proposals are good enough.
>
>
>
> Sheng Wu
> Apache SkyWalking, ShardingSphere, Zipkin
>
> From Wu Sheng 's phone.
>
>
> ------ Original --
> From: zhangli...@apache.org 
> Date: Wed,Jan 30,2019 0:03 PM
> To: dev 
> Cc: Justin Mclean , jmclean 
> Subject: Re: Unapproved Sharding Sphere releases
>
>
>
> Hello Justin,
>
> Thanks for your advice.
> This is a legacy release, which we have discussed on the dev mail list[1]
> before.
> This release is done before the transfer to ASF repo and package rename.
> We are now preparing apache release which begins with new version(4.0.0).
> We will not release non-Apache version any more in the future.
> Any suggestion to identify versions like these kind of releases?
>
>
> [1]
>
> https://lists.apache.org/thread.html/a3bba7e53bfed6d18924b592ecf0533aebc8d307f8c7e399a7fec2cf@%3Cdev.shardingsphere.apache.org%3E
>
> --
>
> Liang Zhang (John)
> Apache ShardingSphere & Dubbo
>
>
> Justin Mclean  于2019年1月30日周三 上午6:23写道：
>
> > Hi,
> >
> > Looking at [1] there seems to have been releases made after you have
> > entered incubation. All releases must be approved by the PPMC and the
> IPMC
> > (usually by voting). Can you please remove these releases and include in
> > your upcoming incubator report what you will do to stop this happening
> > going forward.
> >
> > Thanks,
> > Justin
> >
> > P.S please CC me on any replies as I'm not subscribed to this list
> >
> > 1.https://github.com/apache/incubator-shardingsphere/releases
> >
> >

Re: Unapproved Sharding Sphere releases

[???? Sheng Wu]

Hi


By following the Apache policy, besides the suggestions I gave and done. Just a 
moment ago, I deleted the recent two unapproved releases, 3.1.0.m1 and 3.1.0 at 
GitHub release page[1].


In further, I will help the shardingsphere community to follow the policy.




[1] https://github.com/apache/incubator-shardingsphere/releases

Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From:  Sheng Wu 
Date: Wed,Jan 30,2019 5:54 PM
To: dev , dev 
Cc: Justin Mclean , jmclean 
Subject: Re: Unapproved Sharding Sphere releases



Hi 


I think I agree the Justin's points.
No matter the release happens in Apache org repo or not, it still happened 
after you asked and accepted by Incubator. So, it is not encouraged and not 
following the Apache way.


I propose these adjustments
1. Add statement in GitHub release versions. Saying these are not Apache 
release.
2. Add statement in you website home, document and download pages, saying all 
available releases are not Apache releases
3. After the first approved release, you only says before this version(4.0.0 
maybe) are not Apachre releases.
4. Add statement in GitHub project readme.md for the same thing.


Especially for document pages, this needs to be tagged in clear way. 
I know, those releases in maven central repo are hard to release, and not good 
for the existing community. So, I hope my proposals are good enough.



Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin

From Wu Sheng 's phone.


-- Original --
From: zhangli...@apache.org 
Date: Wed,Jan 30,2019 0:03 PM
To: dev 
Cc: Justin Mclean , jmclean 
Subject: Re: Unapproved Sharding Sphere releases



Hello Justin,

Thanks for your advice.
This is a legacy release, which we have discussed on the dev mail list[1]
before.
This release is done before the transfer to ASF repo and package rename.
We are now preparing apache release which begins with new version(4.0.0).
We will not release non-Apache version any more in the future.
Any suggestion to identify versions like these kind of releases?


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

--

Liang Zhang (John)
Apache ShardingSphere & Dubbo


Justin Mclean  ??2019??1??30?? 6:23??

> Hi,
>
> Looking at [1] there seems to have been releases made after you have
> entered incubation. All releases must be approved by the PPMC and the IPMC
> (usually by voting). Can you please remove these releases and include in
> your upcoming incubator report what you will do to stop this happening
> going forward.
>
> Thanks,
> Justin
>
> P.S please CC me on any replies as I'm not subscribed to this list
>
> 1.https://github.com/apache/incubator-shardingsphere/releases
>
>