Keeping both available for now, with the current three messages (URL,
last commit, and the top of the README.md) on the
commons-rdf/commons-rdf repository that indicate the project has been
moved, is useful for a migration period.

With Git it doesn't matter about the exact timescales for keeping
commons-rdf/commons-rdf in sync with apache/incubator-commonsrdf, as
merging is trivial and pushing is also trivial. Hence, if a fork uses
commons-rdf/commons-rdf as a source, they will not be months out of
date. At most they will be days out of date.

FWIW, I don't mind being the one to push master to
commons-rdf/commons-rdf for a while. It is one extra quick command
that I have done in the past for other projects with similarly
fragmented designs and with Git it really isn't a hassle.

We could turn issues off, but there is a substantial chunk of the
project history that is only available there, so it would be easier
for everyones sake to leave them there.

GitHub doesn't allow Pull Requests to be turned off, as that is not
the point of their system. If we get Pull Requests there, we will
merge them the same way we are currently merging Pull Requests, using
"git merge --no-ff" on the command line. We can't use the GitHub
interface to merge pull requests for apache/incubator-commonsrdf
anyway, per the overall design where a push to git-wip triggers the
update at GitHub, so in terms of where Pull Requests come in from,
there is no difference.

I suggest that we leave it how it is until graduation from the
incubator, when we notify all of the remaining forks of
commons-rdf/commons-rdf where the current repository is at that stage,
as apache/incubator-commonsrdf isn't a permanent fixture anyway, so we
would be reducing the administrative hassle for them from 2 (or more)
fork changes to a single fork change.

I doubt that we would be able to transfer a repository in and then
have it converted to the special "mirror" repositories, and doing so
doesn't help with merging pull requests anyway.



On 31 March 2015 at 21:55, Stian Soiland-Reyes <[email protected]> wrote:
> I'm OK with the git rm +README approach on a non-master default branch
> so that it appears at https://github.com/commons-rdf/commons-rdf/ in
> the browser.
>
> I am not too big fan of keeping
> https://github.com/commons-rdf/commons-rdf/tree/master in sync with
> https://github.com/apache/incubator-commonsrdf/tree/master - who will
> be doing that? Can it be a cron-job somewhere?
>
> What happens if we get issues and pull requests on the
> commons-rdf/commons-rdf repository? Should we turn those features off?
>
> There is a danger of turning the project structure upside down - we
> just transferred commons-rdf to Apache and presumably now the project
> is run within AFS, using these mailing lists etc - yet the old github
> project keeps living on, appearing as a kind of "proper Commons-RDF"
> project where commits to the incubator projects might trickle down
> only when one of the (smaller set of) original committers updates it.
>
> The git rm approach on master might sound cruel to the forks - but
> anyone doing 'git pull' should then notice the change and pick it up
> again from the new location (and hopefully sign up to this mailing
> list). It's not too hard hard to undo the result of this rm locally
> with git.
>
>
> Ideally I think we would have used the GitHub "Transfer" button in
> GitHub to transfer it to Apache (this sets up redirects even at git
> pull level) - but that might not work well with the git.apache.org
> synchronization. I'll check with INFRA if that is something they want
> to do -- what are your views- should we do that if possible?  (That
> should presumably then also be possible when we loose the "incubator-"
> prefix)
>
> On 31 March 2015 at 10:39, Andy Seaborne <[email protected]> wrote:
>> Fair point about existing forks esp as the Apache one is an unstable name
>> because of incubator-* [1].
>>
>> Of the 10 forks , GH is tracking most are people who would understand the
>> move.
>>
>> Shall we leave it as-is and aim to remove it when the project graduates?
>>
>>         Andy
>>
>> [1] https://github.com/apache/incubator-commonsrdf/
>>
>>
>>
>>
>> On 30/03/15 23:03, Peter Ansell wrote:
>>>
>>> There are no divergent master branches at this point, as I did a hard
>>> reset on that commit and moved it to another branch,
>>> old-master-before-asf.
>>>
>>> I would support a git rm on the GitHub visible branch (which is
>>> currently "old-master-before-asf" but can be changed to something else
>>> very easily) of commons-rdf/commons-rdf, but not on the master branch
>>> itself. One of the advantages of Git is that we can mirror the master
>>> branch there, without having casual browsing users able to see that
>>> code, through the help of GitHub with its selection of the visible
>>> branch. That enables us to continue support the existing forks, while
>>> maintaining the public reference that we are currently in the Apache
>>> Incubator.
>>>
>>> On 30 March 2015 at 20:42, Andy Seaborne <[email protected]> wrote:
>>>>
>>>> I like the "git rm" approach - better to go round clearing up as much as
>>>> possible now.  Short term it might be more confusing, but long term it's
>>>> clearer IMO.
>>>>
>>>>          Andy
>>>>
>>>>
>>>>
>>>> On 30/03/15 08:42, Stian Soiland-Reyes wrote:
>>>>>
>>>>>
>>>>> For Taverna I just left a commit with git rm -r and a new README.md with
>>>>> the new location.
>>>>>
>>>>> https://github.com/taverna/taverna-scufl2
>>>>>
>>>>> As the mirroring will go back again to
>>>>> https://github.com/apache/incubator-commonsrdf there is no concern about
>>>>> divergent commits, it would just be confusing if there are two (now
>>>>> three)
>>>>> diverged master branches.
>>>>> On 30 Mar 2015 07:34, "Sergio Fernández" <[email protected]> wrote:
>>>>>
>>>>>> Right, that commit will cause troubles with the mirroring... That
>>>>>> solution
>>>>>> may work for a time. But we could think about removing it completely
>>>>>> from
>>>>>> github (we have the bundle attached to COMMONSRDF-1 and the master
>>>>>> branch
>>>>>> history is alive in our current repo).
>>>>>>
>>>>>>
>>>>>> On 30/03/15 02:12, Peter Ansell wrote:
>>>>>>
>>>>>>> Sorry, I wasn't aware that Sergio had already created a commit to push
>>>>>>> solely to GitHub. That will create two divergent Git histories if we
>>>>>>> let it stay on the master branch, which will cause more confusion than
>>>>>>> it is worth.
>>>>>>>
>>>>>>> A workaround that I have just tried is to push Sergio's commit:
>>>>>>>
>>>>>>> https://github.com/commons-rdf/commons-rdf/commit/
>>>>>>> 911e33aa9d7442464b3e9c6df1f8899a35d0fd44
>>>>>>>
>>>>>>> to a separate branch, "old-master-before-asf" and changed what GitHub
>>>>>>> thinks the master branch to be that one so it is displayed.
>>>>>>>
>>>>>>> Then I reset the master branch to remove that commit so it is
>>>>>>> identical to the history in the ASF repository.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>> On 30 March 2015 at 10:56, Peter Ansell <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 30 March 2015 at 10:30, John D. Ament <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Sergio,
>>>>>>>>>
>>>>>>>>> Are there plans to mark the github repo as read only and direct
>>>>>>>>> folks
>>>>>>>>> to
>>>>>>>>> the ASF repos?  I see a link was added, but any plans to remove the
>>>>>>>>> code
>>>>>>>>> from the repo?
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>
>>>>>>>> I have been mirroring the code there over the weekend to ease the
>>>>>>>> transfer period for others and I changed the description to refer to
>>>>>>>> the ASF version.
>>>>>>>>
>>>>>>>> What advantage would there be to wiping the code in the
>>>>>>>> commons-rdf/commons-rdf repository, given that it contains the same
>>>>>>>> root Git history as the ASF repository and hence is still compatible
>>>>>>>> as a source for cloning at this point. Not sure how to make a
>>>>>>>> repository read-only on GitHub, but that could be an option once an
>>>>>>>> initial transfer period is complete.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Sergio Fernández
>>>>>> Partner Technology Manager
>>>>>> Redlink GmbH
>>>>>> m: +43 660 2747 925
>>>>>> e: [email protected]
>>>>>> w: http://redlink.co
>>>>>>
>>>>>
>>>>
>>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718

Reply via email to