incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <apache....@gmail.com>
Subject Re: Unapproved Sharding Sphere releases
Date Sat, 09 Feb 2019 16:26:21 GMT
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.sheng@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 <cml@apache.org>
> Date: Sat,Feb 9,2019 4:34 AM
> To: general <general@incubator.apache.org>
> Cc: dev <dev@shardingsphere.apache.org>
> Subject: Re: Unapproved Sharding Sphere releases
> 
> 
> 
> 
> 
>> On Feb 7, 2019, at 1:52 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>> 
>> 
>> 
>>> On Feb 7, 2019, at 1:44 PM, Craig Russell <apache.clr@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 <mailto:clr@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

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