You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by 吴晟 Sheng Wu <wu...@foxmail.com> on 2019/02/01 14:50:54 UTC
Re: Unapproved Sharding Sphere releases
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 <wu...@foxmail.com>
Date: Wed,Jan 30,2019 5:54 PM
To: dev <de...@shardingsphere.apache.org>, dev <de...@shardingsphere.apache.org>
Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
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: zhangliang@apache.org <zh...@apache.org>
Date: Wed,Jan 30,2019 0:03 PM
To: dev <de...@shardingsphere.apache.org>
Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
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 <jm...@apache.org> 于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
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 7, 2019, at 1:55 PM, Justin Mclean <ju...@classsoftware.com> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Unapproved Sharding Sphere releases
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Unapproved Sharding Sphere releases
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 7, 2019, at 1:24 PM, Justin Mclean <ju...@classsoftware.com> 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/ <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
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Posted by Craig Russell <ap...@gmail.com>.
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 <wu...@foxmail.com> 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 <cm...@apache.org>
> Date: Sat,Feb 9,2019 4:34 AM
> To: general <ge...@incubator.apache.org>
> Cc: dev <de...@shardingsphere.apache.org>
> Subject: Re: Unapproved Sharding Sphere releases
>
>
>
>
>
>> On Feb 7, 2019, at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>>
>>
>>
>>> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> 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
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
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 <wu...@foxmail.com> 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 <cm...@apache.org>
> Date: Sat,Feb 9,2019 4:34 AM
> To: general <ge...@incubator.apache.org>
> Cc: dev <de...@shardingsphere.apache.org>
> Subject: Re: Unapproved Sharding Sphere releases
>
>
>
>
>
>> On Feb 7, 2019, at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>>
>>
>>
>>> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> 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
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by 吴晟 Sheng Wu <wu...@foxmail.com>.
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 <cm...@apache.org>
Date: Sat,Feb 9,2019 4:34 AM
To: general <ge...@incubator.apache.org>
Cc: dev <de...@shardingsphere.apache.org>
Subject: Re: Unapproved Sharding Sphere releases
> On Feb 7, 2019, at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>
>
>
>> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> 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
Posted by 吴晟 Sheng Wu <wu...@foxmail.com>.
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 <cm...@apache.org>
Date: Sat,Feb 9,2019 4:34 AM
To: general <ge...@incubator.apache.org>
Cc: dev <de...@shardingsphere.apache.org>
Subject: Re: Unapproved Sharding Sphere releases
> On Feb 7, 2019, at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>
>
>
>> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> 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
Posted by Chris Lambertus <cm...@apache.org>.
> On Feb 7, 2019, at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>
>
>
>> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> 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
Posted by Chris Lambertus <cm...@apache.org>.
> On Feb 7, 2019, at 1:52 PM, Dave Fisher <da...@comcast.net> wrote:
>
>
>
>> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> 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
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> wrote:
>
>> On Feb 7, 2019, at 11:02 AM, Dave Fisher <da...@comcast.net> wrote:
>>
>>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 <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
> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Unapproved Sharding Sphere releases
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 7, 2019, at 1:44 PM, Craig Russell <ap...@gmail.com> wrote:
>
>> On Feb 7, 2019, at 11:02 AM, Dave Fisher <da...@comcast.net> wrote:
>>
>>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 <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
> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
> On Feb 7, 2019, at 11:02 AM, Dave Fisher <da...@comcast.net> wrote:
>
>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 <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
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
> On Feb 7, 2019, at 11:02 AM, Dave Fisher <da...@comcast.net> wrote:
>
>> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-17289 <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
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 7, 2019, at 10:46 AM, Craig Russell <ap...@gmail.com> wrote:
>
> Hi Dave,
>
>> On Feb 7, 2019, at 9:12 AM, Dave Fisher <da...@comcast.net> wrote:
>>
>>
>>
>>> On Feb 7, 2019, at 8:31 AM, Craig Russell <ap...@gmail.com> wrote:
>>>
>>>
>>>
>>>> On Feb 6, 2019, at 10:31 PM, Justin Mclean <ju...@classsoftware.com> 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/ <https://github.com/sharding-sphere/sharding-sphere.git>* 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 <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-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>>>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>>>
>>>
>>> Craig L Russell
>>> clr@apache.org <ma...@apache.org>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
Hi Dave,
> On Feb 7, 2019, at 9:12 AM, Dave Fisher <da...@comcast.net> wrote:
>
>
>
>> On Feb 7, 2019, at 8:31 AM, Craig Russell <ap...@gmail.com> wrote:
>>
>>
>>
>>> On Feb 6, 2019, at 10:31 PM, Justin Mclean <ju...@classsoftware.com> 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/ <https://github.com/sharding-sphere/sharding-sphere.git>* 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-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>>
>>
>> Craig L Russell
>> clr@apache.org <ma...@apache.org>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Dave Fisher <da...@comcast.net>.
> On Feb 7, 2019, at 8:31 AM, Craig Russell <ap...@gmail.com> wrote:
>
>
>
>> On Feb 6, 2019, at 10:31 PM, Justin Mclean <ju...@classsoftware.com> 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/ <https://github.com/sharding-sphere/sharding-sphere.git>* 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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> clr@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
> On Feb 6, 2019, at 10:31 PM, Justin Mclean <ju...@classsoftware.com> 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/ <https://github.com/sharding-sphere/sharding-sphere.git>* 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Unapproved Sharding Sphere releases
Posted by Justin Mclean <ju...@classsoftware.com>.
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/ <https://github.com/sharding-sphere/sharding-sphere.git>* 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
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, zhangliang@apache.org wrote:
>
> I updated wiki for remove unapproved releases.
>
> ------------------
>
> Liang Zhang (John)
> Apache ShardingSphere & Dubbo
>
>
> 吴晟 Sheng Wu <wu...@foxmail.com> 于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 <wu...@foxmail.com>
>> Date: Wed,Jan 30,2019 5:54 PM
>> To: dev <de...@shardingsphere.apache.org>, dev <
>> dev@shardingsphere.apache.org>
>> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
>> 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: zhangliang@apache.org <zh...@apache.org>
>> Date: Wed,Jan 30,2019 0:03 PM
>> To: dev <de...@shardingsphere.apache.org>
>> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
>> 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 <jm...@apache.org> 于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
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by Craig Russell <ap...@gmail.com>.
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, zhangliang@apache.org wrote:
>
> I updated wiki for remove unapproved releases.
>
> ------------------
>
> Liang Zhang (John)
> Apache ShardingSphere & Dubbo
>
>
> 吴晟 Sheng Wu <wu...@foxmail.com> 于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 <wu...@foxmail.com>
>> Date: Wed,Jan 30,2019 5:54 PM
>> To: dev <de...@shardingsphere.apache.org>, dev <
>> dev@shardingsphere.apache.org>
>> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
>> 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: zhangliang@apache.org <zh...@apache.org>
>> Date: Wed,Jan 30,2019 0:03 PM
>> To: dev <de...@shardingsphere.apache.org>
>> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
>> 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 <jm...@apache.org> 于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
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Unapproved Sharding Sphere releases
Posted by "zhangliang@apache.org" <zh...@apache.org>.
I updated wiki for remove unapproved releases.
------------------
Liang Zhang (John)
Apache ShardingSphere & Dubbo
吴晟 Sheng Wu <wu...@foxmail.com> 于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 <wu...@foxmail.com>
> Date: Wed,Jan 30,2019 5:54 PM
> To: dev <de...@shardingsphere.apache.org>, dev <
> dev@shardingsphere.apache.org>
> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
> 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: zhangliang@apache.org <zh...@apache.org>
> Date: Wed,Jan 30,2019 0:03 PM
> To: dev <de...@shardingsphere.apache.org>
> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
> 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 <jm...@apache.org> 于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
Posted by "zhangliang@apache.org" <zh...@apache.org>.
I updated wiki for remove unapproved releases.
------------------
Liang Zhang (John)
Apache ShardingSphere & Dubbo
吴晟 Sheng Wu <wu...@foxmail.com> 于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 <wu...@foxmail.com>
> Date: Wed,Jan 30,2019 5:54 PM
> To: dev <de...@shardingsphere.apache.org>, dev <
> dev@shardingsphere.apache.org>
> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
> 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: zhangliang@apache.org <zh...@apache.org>
> Date: Wed,Jan 30,2019 0:03 PM
> To: dev <de...@shardingsphere.apache.org>
> Cc: Justin Mclean <ju...@classsoftware.com>, jmclean <jm...@apache.org>
> 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 <jm...@apache.org> 于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
> >
> >