2015-04-01 2:02 GMT+02:00 Peter Ansell <[email protected]>:

> 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.
>

FWIW, we already have an empty repo [1] waiting for you after incubation.

Benedikt

[1] git://git.apache.org/commons-rdf.git


>
>
>
> 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
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Reply via email to