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.sh...@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 <c...@apache.org> > Date: Sat,Feb 9,2019 4:34 AM > To: general <general@incubator.apache.org> > Cc: dev <d...@shardingsphere.apache.org> > Subject: Re: Unapproved Sharding Sphere releases > > > > > >> On Feb 7, 2019, at 1:52 PM, Dave Fisher <dave2w...@comcast.net> wrote: >> >> >> >>> On Feb 7, 2019, at 1:44 PM, Craig Russell <apache....@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 c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
