You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Steve Lawrence <sl...@apache.org> on 2017/10/24 15:48:35 UTC
Import of Code to ASF Infrastructure
An issue came up on the Apache Legal bug tracker that has a similar
situation to ours.
https://issues.apache.org/jira/browse/LEGAL-339
Apache Heron is in a similar stage to us in incubation. They are working
to transition over to the ASF infrastructure. Their original code is
under a permissive license (Apache v2), but they do not have SGAs in
place yet, and they wanted to know if they could import their code to
ASF. The result of the issue is that since the code is under a
permissive license, it is okay to import the code to the ASF git, and
just not change any license headers yet. Once the remaining SGAs are in
place we can change the headers. We can even do releases, but it will
prevent graduation, but I suspect we'll have SGAs in place before our
first ASF release.
Related, I was thinking that if we were to do it, now would be a good
time to rename all the old branches and tags to use the new Branch & Tag
workflow [1] so that all future tags/branch are consistent with the old.
This would just mean that all rc/alpha tags would have a 'v' prepended
(e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
-> rel/v1.0.0), and all branches have a 'support/v' prepended and the
last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
change what the tags/branches point to, just changes their names.
Since this would mean the tags change (which git tends to avoid), this
will mean that we should all clone the new repo and work out of that, no
longer using our old clones. This will ensure no old tags stick around.
For any ongoing work, something like git format-patch would be a good
method to get the changes to the new repo.
Any thoughts/concerns with this?
- Steve
[1]
https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
Re: Import of Code to ASF Infrastructure
Posted by Steve Lawrence <sl...@apache.org>.
On 10/24/2017 02:11 PM, John D. Ament wrote:
> Steve,
>
> On Tue, Oct 24, 2017 at 2:01 PM Steve Lawrence <sl...@apache.org> wrote:
>
>> The problem is you really can't delete tags in git, so now is really the
>> best time to do it since we're moving repos.
>>
>
> Yes you can delete tags. In git, tags are not immutable.
Ah you're right, I thought tags were a bit more restrictive about being
deleted, but it looks like that's not the case. We'll all probably want
to delete the old tags locally so they don't accidentally come back with
a git push --tags, but that's not too big of a deal.
I retract the below stuff. If there are no objections with the renaming
of tags/branches and just adding the ASF repo as a new remote to your
existing repo, I'll work on getting that repo set up tomorrow.
>
>>
>> Is the disruption having to move your local review branches from one
>> repo to another? If so, I think I found a decent solution to make a
>> clean cut over with just a handful of commands:
>>
>> Make sure all your changes are committed to a review branch in your old
>> repo. Move your current repo to a backup location:
>>
>> $ mv daffodil.git daffodil-ncsa.git
>>
>> Now clone the ASF git repo that will contain only the new tags/branches,
>> this will be the new git repo:
>>
>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
>> $ cd daffodil.git
>>
>
> you're better off just adding a remote to the ASF than deleting the repo.
Makes sense.
>
> $ git remote add asf
> https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git
>
>
>>
>> Add your local backup daffodil NCSA repo as a remote, specifying no tags
>> and all the review branches you want via the -t option. There should be
>> one -t option for each branch:
>>
>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
>> $ git fetch local-daffodil-ncsa
>>
>> Create a local branch for each of the fetched review branches:
>>
>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
>> -f2` $BRANCH; done
>>
>> Now remove the old local-daffodil-ncsa remote:
>>
>> $ git remote remove local-daffodil-ncsa
>>
>> You should just be left with all the new tags/branches and your review
>> branches.
>>
>> Does that seem like a reasonable way to cutover without too much
>> disruption? I could turn this into a script that will do the cutover
>> automatically if that would make things easier?
>>
>> - Steve
>>
>> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
>>> This will be massively disruptive to me. I have like 7 or 8 outstanding
>> branches right now.
>>>
>>>
>>> How about we add the new tags and branches and leave the old ones there
>> for now.
>>>
>>>
>>>
>>> ________________________________
>>> From: Steve Lawrence <sl...@apache.org>
>>> Sent: Tuesday, October 24, 2017 11:48:35 AM
>>> To: dev@daffodil.apache.org
>>> Subject: Import of Code to ASF Infrastructure
>>>
>>> An issue came up on the Apache Legal bug tracker that has a similar
>>> situation to ours.
>>>
>>> https://issues.apache.org/jira/browse/LEGAL-339
>>>
>>> Apache Heron is in a similar stage to us in incubation. They are working
>>> to transition over to the ASF infrastructure. Their original code is
>>> under a permissive license (Apache v2), but they do not have SGAs in
>>> place yet, and they wanted to know if they could import their code to
>>> ASF. The result of the issue is that since the code is under a
>>> permissive license, it is okay to import the code to the ASF git, and
>>> just not change any license headers yet. Once the remaining SGAs are in
>>> place we can change the headers. We can even do releases, but it will
>>> prevent graduation, but I suspect we'll have SGAs in place before our
>>> first ASF release.
>>>
>>> Related, I was thinking that if we were to do it, now would be a good
>>> time to rename all the old branches and tags to use the new Branch & Tag
>>> workflow [1] so that all future tags/branch are consistent with the old.
>>> This would just mean that all rc/alpha tags would have a 'v' prepended
>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
>>> change what the tags/branches point to, just changes their names.
>>>
>>> Since this would mean the tags change (which git tends to avoid), this
>>> will mean that we should all clone the new repo and work out of that, no
>>> longer using our old clones. This will ensure no old tags stick around.
>>> For any ongoing work, something like git format-patch would be a good
>>> method to get the changes to the new repo.
>>>
>>> Any thoughts/concerns with this?
>>>
>>> - Steve
>>>
>>>
>>> [1]
>>>
>> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
>>>
>>
>>
>
Re: Import of Code to ASF Infrastructure
Posted by "John D. Ament" <jo...@apache.org>.
Steve,
On Tue, Oct 24, 2017 at 2:01 PM Steve Lawrence <sl...@apache.org> wrote:
> The problem is you really can't delete tags in git, so now is really the
> best time to do it since we're moving repos.
>
Yes you can delete tags. In git, tags are not immutable.
>
> Is the disruption having to move your local review branches from one
> repo to another? If so, I think I found a decent solution to make a
> clean cut over with just a handful of commands:
>
> Make sure all your changes are committed to a review branch in your old
> repo. Move your current repo to a backup location:
>
> $ mv daffodil.git daffodil-ncsa.git
>
> Now clone the ASF git repo that will contain only the new tags/branches,
> this will be the new git repo:
>
> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
> $ cd daffodil.git
>
you're better off just adding a remote to the ASF than deleting the repo.
$ git remote add asf
https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git
>
> Add your local backup daffodil NCSA repo as a remote, specifying no tags
> and all the review branches you want via the -t option. There should be
> one -t option for each branch:
>
> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
> $ git fetch local-daffodil-ncsa
>
> Create a local branch for each of the fetched review branches:
>
> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
> -f2` $BRANCH; done
>
> Now remove the old local-daffodil-ncsa remote:
>
> $ git remote remove local-daffodil-ncsa
>
> You should just be left with all the new tags/branches and your review
> branches.
>
> Does that seem like a reasonable way to cutover without too much
> disruption? I could turn this into a script that will do the cutover
> automatically if that would make things easier?
>
> - Steve
>
> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
> > This will be massively disruptive to me. I have like 7 or 8 outstanding
> branches right now.
> >
> >
> > How about we add the new tags and branches and leave the old ones there
> for now.
> >
> >
> >
> > ________________________________
> > From: Steve Lawrence <sl...@apache.org>
> > Sent: Tuesday, October 24, 2017 11:48:35 AM
> > To: dev@daffodil.apache.org
> > Subject: Import of Code to ASF Infrastructure
> >
> > An issue came up on the Apache Legal bug tracker that has a similar
> > situation to ours.
> >
> > https://issues.apache.org/jira/browse/LEGAL-339
> >
> > Apache Heron is in a similar stage to us in incubation. They are working
> > to transition over to the ASF infrastructure. Their original code is
> > under a permissive license (Apache v2), but they do not have SGAs in
> > place yet, and they wanted to know if they could import their code to
> > ASF. The result of the issue is that since the code is under a
> > permissive license, it is okay to import the code to the ASF git, and
> > just not change any license headers yet. Once the remaining SGAs are in
> > place we can change the headers. We can even do releases, but it will
> > prevent graduation, but I suspect we'll have SGAs in place before our
> > first ASF release.
> >
> > Related, I was thinking that if we were to do it, now would be a good
> > time to rename all the old branches and tags to use the new Branch & Tag
> > workflow [1] so that all future tags/branch are consistent with the old.
> > This would just mean that all rc/alpha tags would have a 'v' prepended
> > (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
> > -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
> > last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
> > change what the tags/branches point to, just changes their names.
> >
> > Since this would mean the tags change (which git tends to avoid), this
> > will mean that we should all clone the new repo and work out of that, no
> > longer using our old clones. This will ensure no old tags stick around.
> > For any ongoing work, something like git format-patch would be a good
> > method to get the changes to the new repo.
> >
> > Any thoughts/concerns with this?
> >
> > - Steve
> >
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
> >
>
>
Re: Import of Code to ASF Infrastructure
Posted by Steve Lawrence <sl...@apache.org>.
The git repo is now populated with the new tag and branch names. The ASF
repo is here:
https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git
The GitHub mirror is:
https://github.com/apache/incubator-daffodil
You can now create a GitHub fork of the mirror and add your fork and the
ASF repo as remotes to your existing repo. As a reminder, the code
contributor workflow for is available here:
https://cwiki.apache.org/confluence/display/DAFFODIL/Code+Contributor+Workflow
- Steve
On 10/25/2017 09:47 AM, John D. Ament wrote:
> The writable URL is https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git
>
> John
>
> On Wed, Oct 25, 2017 at 9:46 AM John D. Ament <johndament@apache.org
> <ma...@apache.org>> wrote:
>
> You should have access. I believe I created it upon request.
>
> John
>
> On Wed, Oct 25, 2017 at 8:07 AM Steve Lawrence <slawrence@apache.org
> <ma...@apache.org>> wrote:
>
> It looks like someone has already created an empty repo for us:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-daffodil.git
>
> And the github mirror:
>
> https://github.com/apache/incubator-daffodil
>
> I haven't tried pushing anything yet so I'm not sure if we have permissions.
>
> - Steve
>
> On 10/25/2017 08:04 AM, John D. Ament wrote:
> > All,
> >
> > Do you want to aim to get a repo created on the ASF side?
> >
> > John
> >
> > On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence <slawrence@apache.org
> <ma...@apache.org>> wrote:
> >
> >> Yes, branches/tags are essentially renamed. All commit hashes stay the
> >> same. I've made the changes and pushed a test repo to my github:
> >>
> >> https://github.com/stevedlawrence/daffodil-new.git
> >>
> >> If you want to test this, you should be able to add this as a new remote
> >> and see the new branch names/tags.
> >>
> >> This renames all version branches to 'support/vN.N.x', all release tags
> >> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also now
> >> signed in accordance with the tag/branch workflow.
> >>
> >> If this looks good, I can push it to the ASF repo and we can start
> >> transitioning to that + github for the new workflow.
> >>
> >> - Steve
> >>
> >> On 10/25/2017 01:26 AM, Mike Beckerle wrote:
> >>> So branches can just be renamed right?
> >>>
> >>> What I care about is the branches and the commit hashes. If those are
> >> preserved, then the tags don't matter much to me.
> >>>
> >>>
> >>>
> >>> -------- Original message --------
> >>> From: Steve Lawrence <slawrence@apache.org
> <ma...@apache.org>>
> >>> Date: 10/24/17 12:01 PM (GMT-07:00)
> >>> To: dev@daffodil.apache.org <ma...@daffodil.apache.org>, Mike
> Beckerle <mbeckerle@tresys.com <ma...@tresys.com>>
> >>> Subject: Re: Import of Code to ASF Infrastructure
> >>>
> >>> The problem is you really can't delete tags in git, so now is
> really the
> >>> best time to do it since we're moving repos.
> >>>
> >>> Is the disruption having to move your local review branches from one
> >>> repo to another? If so, I think I found a decent solution to make a
> >>> clean cut over with just a handful of commands:
> >>>
> >>> Make sure all your changes are committed to a review branch in your old
> >>> repo. Move your current repo to a backup location:
> >>>
> >>> $ mv daffodil.git daffodil-ncsa.git
> >>>
> >>> Now clone the ASF git repo that will contain only the new
> tags/branches,
> >>> this will be the new git repo:
> >>>
> >>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
> >>> $ cd daffodil.git
> >>>
> >>> Add your local backup daffodil NCSA repo as a remote, specifying no
> tags
> >>> and all the review branches you want via the -t option. There should be
> >>> one -t option for each branch:
> >>>
> >>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
> >>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
> >>> $ git fetch local-daffodil-ncsa
> >>>
> >>> Create a local branch for each of the fetched review branches:
> >>>
> >>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH |
> cut -d/
> >>> -f2` $BRANCH; done
> >>>
> >>> Now remove the old local-daffodil-ncsa remote:
> >>>
> >>> $ git remote remove local-daffodil-ncsa
> >>>
> >>> You should just be left with all the new tags/branches and your review
> >>> branches.
> >>>
> >>> Does that seem like a reasonable way to cutover without too much
> >>> disruption? I could turn this into a script that will do the cutover
> >>> automatically if that would make things easier?
> >>>
> >>> - Steve
> >>>
> >>> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
> >>>> This will be massively disruptive to me. I have like 7 or 8
> >> outstanding branches right now.
> >>>>
> >>>>
> >>>> How about we add the new tags and branches and leave the old ones
> there
> >> for now.
> >>>>
> >>>>
> >>>>
> >>>> ________________________________
> >>>> From: Steve Lawrence <slawrence@apache.org
> <ma...@apache.org>>
> >>>> Sent: Tuesday, October 24, 2017 11:48:35 AM
> >>>> To: dev@daffodil.apache.org <ma...@daffodil.apache.org>
> >>>> Subject: Import of Code to ASF Infrastructure
> >>>>
> >>>> An issue came up on the Apache Legal bug tracker that has a similar
> >>>> situation to ours.
> >>>>
> >>>> https://issues.apache.org/jira/browse/LEGAL-339
> >>>>
> >>>> Apache Heron is in a similar stage to us in incubation. They are
> working
> >>>> to transition over to the ASF infrastructure. Their original code is
> >>>> under a permissive license (Apache v2), but they do not have SGAs in
> >>>> place yet, and they wanted to know if they could import their code to
> >>>> ASF. The result of the issue is that since the code is under a
> >>>> permissive license, it is okay to import the code to the ASF git, and
> >>>> just not change any license headers yet. Once the remaining SGAs
> are in
> >>>> place we can change the headers. We can even do releases, but it will
> >>>> prevent graduation, but I suspect we'll have SGAs in place before our
> >>>> first ASF release.
> >>>>
> >>>> Related, I was thinking that if we were to do it, now would be a good
> >>>> time to rename all the old branches and tags to use the new Branch
> & Tag
> >>>> workflow [1] so that all future tags/branch are consistent with
> the old.
> >>>> This would just mean that all rc/alpha tags would have a 'v' prepended
> >>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g.
> 1.0.0
> >>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
> >>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
> >>>> change what the tags/branches point to, just changes their names.
> >>>>
> >>>> Since this would mean the tags change (which git tends to avoid), this
> >>>> will mean that we should all clone the new repo and work out of
> that, no
> >>>> longer using our old clones. This will ensure no old tags stick
> around.
> >>>> For any ongoing work, something like git format-patch would be a good
> >>>> method to get the changes to the new repo.
> >>>>
> >>>> Any thoughts/concerns with this?
> >>>>
> >>>> - Steve
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
Re: Import of Code to ASF Infrastructure
Posted by "John D. Ament" <jo...@apache.org>.
The writable URL is
https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git
John
On Wed, Oct 25, 2017 at 9:46 AM John D. Ament <jo...@apache.org> wrote:
> You should have access. I believe I created it upon request.
>
> John
>
> On Wed, Oct 25, 2017 at 8:07 AM Steve Lawrence <sl...@apache.org>
> wrote:
>
>> It looks like someone has already created an empty repo for us:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-daffodil.git
>>
>> And the github mirror:
>>
>> https://github.com/apache/incubator-daffodil
>>
>> I haven't tried pushing anything yet so I'm not sure if we have
>> permissions.
>>
>> - Steve
>>
>> On 10/25/2017 08:04 AM, John D. Ament wrote:
>> > All,
>> >
>> > Do you want to aim to get a repo created on the ASF side?
>> >
>> > John
>> >
>> > On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence <sl...@apache.org>
>> wrote:
>> >
>> >> Yes, branches/tags are essentially renamed. All commit hashes stay the
>> >> same. I've made the changes and pushed a test repo to my github:
>> >>
>> >> https://github.com/stevedlawrence/daffodil-new.git
>> >>
>> >> If you want to test this, you should be able to add this as a new
>> remote
>> >> and see the new branch names/tags.
>> >>
>> >> This renames all version branches to 'support/vN.N.x', all release tags
>> >> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also
>> now
>> >> signed in accordance with the tag/branch workflow.
>> >>
>> >> If this looks good, I can push it to the ASF repo and we can start
>> >> transitioning to that + github for the new workflow.
>> >>
>> >> - Steve
>> >>
>> >> On 10/25/2017 01:26 AM, Mike Beckerle wrote:
>> >>> So branches can just be renamed right?
>> >>>
>> >>> What I care about is the branches and the commit hashes. If those are
>> >> preserved, then the tags don't matter much to me.
>> >>>
>> >>>
>> >>>
>> >>> -------- Original message --------
>> >>> From: Steve Lawrence <sl...@apache.org>
>> >>> Date: 10/24/17 12:01 PM (GMT-07:00)
>> >>> To: dev@daffodil.apache.org, Mike Beckerle <mb...@tresys.com>
>> >>> Subject: Re: Import of Code to ASF Infrastructure
>> >>>
>> >>> The problem is you really can't delete tags in git, so now is really
>> the
>> >>> best time to do it since we're moving repos.
>> >>>
>> >>> Is the disruption having to move your local review branches from one
>> >>> repo to another? If so, I think I found a decent solution to make a
>> >>> clean cut over with just a handful of commands:
>> >>>
>> >>> Make sure all your changes are committed to a review branch in your
>> old
>> >>> repo. Move your current repo to a backup location:
>> >>>
>> >>> $ mv daffodil.git daffodil-ncsa.git
>> >>>
>> >>> Now clone the ASF git repo that will contain only the new
>> tags/branches,
>> >>> this will be the new git repo:
>> >>>
>> >>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
>> >>> $ cd daffodil.git
>> >>>
>> >>> Add your local backup daffodil NCSA repo as a remote, specifying no
>> tags
>> >>> and all the review branches you want via the -t option. There should
>> be
>> >>> one -t option for each branch:
>> >>>
>> >>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
>> >>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
>> >>> $ git fetch local-daffodil-ncsa
>> >>>
>> >>> Create a local branch for each of the fetched review branches:
>> >>>
>> >>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut
>> -d/
>> >>> -f2` $BRANCH; done
>> >>>
>> >>> Now remove the old local-daffodil-ncsa remote:
>> >>>
>> >>> $ git remote remove local-daffodil-ncsa
>> >>>
>> >>> You should just be left with all the new tags/branches and your review
>> >>> branches.
>> >>>
>> >>> Does that seem like a reasonable way to cutover without too much
>> >>> disruption? I could turn this into a script that will do the cutover
>> >>> automatically if that would make things easier?
>> >>>
>> >>> - Steve
>> >>>
>> >>> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
>> >>>> This will be massively disruptive to me. I have like 7 or 8
>> >> outstanding branches right now.
>> >>>>
>> >>>>
>> >>>> How about we add the new tags and branches and leave the old ones
>> there
>> >> for now.
>> >>>>
>> >>>>
>> >>>>
>> >>>> ________________________________
>> >>>> From: Steve Lawrence <sl...@apache.org>
>> >>>> Sent: Tuesday, October 24, 2017 11:48:35 AM
>> >>>> To: dev@daffodil.apache.org
>> >>>> Subject: Import of Code to ASF Infrastructure
>> >>>>
>> >>>> An issue came up on the Apache Legal bug tracker that has a similar
>> >>>> situation to ours.
>> >>>>
>> >>>> https://issues.apache.org/jira/browse/LEGAL-339
>> >>>>
>> >>>> Apache Heron is in a similar stage to us in incubation. They are
>> working
>> >>>> to transition over to the ASF infrastructure. Their original code is
>> >>>> under a permissive license (Apache v2), but they do not have SGAs in
>> >>>> place yet, and they wanted to know if they could import their code to
>> >>>> ASF. The result of the issue is that since the code is under a
>> >>>> permissive license, it is okay to import the code to the ASF git, and
>> >>>> just not change any license headers yet. Once the remaining SGAs are
>> in
>> >>>> place we can change the headers. We can even do releases, but it will
>> >>>> prevent graduation, but I suspect we'll have SGAs in place before our
>> >>>> first ASF release.
>> >>>>
>> >>>> Related, I was thinking that if we were to do it, now would be a good
>> >>>> time to rename all the old branches and tags to use the new Branch &
>> Tag
>> >>>> workflow [1] so that all future tags/branch are consistent with the
>> old.
>> >>>> This would just mean that all rc/alpha tags would have a 'v'
>> prepended
>> >>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g.
>> 1.0.0
>> >>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
>> >>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
>> >>>> change what the tags/branches point to, just changes their names.
>> >>>>
>> >>>> Since this would mean the tags change (which git tends to avoid),
>> this
>> >>>> will mean that we should all clone the new repo and work out of
>> that, no
>> >>>> longer using our old clones. This will ensure no old tags stick
>> around.
>> >>>> For any ongoing work, something like git format-patch would be a good
>> >>>> method to get the changes to the new repo.
>> >>>>
>> >>>> Any thoughts/concerns with this?
>> >>>>
>> >>>> - Steve
>> >>>>
>> >>>>
>> >>>> [1]
>> >>>>
>> >>
>> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>>
>>
Re: Import of Code to ASF Infrastructure
Posted by "John D. Ament" <jo...@apache.org>.
You should have access. I believe I created it upon request.
John
On Wed, Oct 25, 2017 at 8:07 AM Steve Lawrence <sl...@apache.org> wrote:
> It looks like someone has already created an empty repo for us:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-daffodil.git
>
> And the github mirror:
>
> https://github.com/apache/incubator-daffodil
>
> I haven't tried pushing anything yet so I'm not sure if we have
> permissions.
>
> - Steve
>
> On 10/25/2017 08:04 AM, John D. Ament wrote:
> > All,
> >
> > Do you want to aim to get a repo created on the ASF side?
> >
> > John
> >
> > On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence <sl...@apache.org>
> wrote:
> >
> >> Yes, branches/tags are essentially renamed. All commit hashes stay the
> >> same. I've made the changes and pushed a test repo to my github:
> >>
> >> https://github.com/stevedlawrence/daffodil-new.git
> >>
> >> If you want to test this, you should be able to add this as a new remote
> >> and see the new branch names/tags.
> >>
> >> This renames all version branches to 'support/vN.N.x', all release tags
> >> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also now
> >> signed in accordance with the tag/branch workflow.
> >>
> >> If this looks good, I can push it to the ASF repo and we can start
> >> transitioning to that + github for the new workflow.
> >>
> >> - Steve
> >>
> >> On 10/25/2017 01:26 AM, Mike Beckerle wrote:
> >>> So branches can just be renamed right?
> >>>
> >>> What I care about is the branches and the commit hashes. If those are
> >> preserved, then the tags don't matter much to me.
> >>>
> >>>
> >>>
> >>> -------- Original message --------
> >>> From: Steve Lawrence <sl...@apache.org>
> >>> Date: 10/24/17 12:01 PM (GMT-07:00)
> >>> To: dev@daffodil.apache.org, Mike Beckerle <mb...@tresys.com>
> >>> Subject: Re: Import of Code to ASF Infrastructure
> >>>
> >>> The problem is you really can't delete tags in git, so now is really
> the
> >>> best time to do it since we're moving repos.
> >>>
> >>> Is the disruption having to move your local review branches from one
> >>> repo to another? If so, I think I found a decent solution to make a
> >>> clean cut over with just a handful of commands:
> >>>
> >>> Make sure all your changes are committed to a review branch in your old
> >>> repo. Move your current repo to a backup location:
> >>>
> >>> $ mv daffodil.git daffodil-ncsa.git
> >>>
> >>> Now clone the ASF git repo that will contain only the new
> tags/branches,
> >>> this will be the new git repo:
> >>>
> >>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
> >>> $ cd daffodil.git
> >>>
> >>> Add your local backup daffodil NCSA repo as a remote, specifying no
> tags
> >>> and all the review branches you want via the -t option. There should be
> >>> one -t option for each branch:
> >>>
> >>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
> >>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
> >>> $ git fetch local-daffodil-ncsa
> >>>
> >>> Create a local branch for each of the fetched review branches:
> >>>
> >>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut
> -d/
> >>> -f2` $BRANCH; done
> >>>
> >>> Now remove the old local-daffodil-ncsa remote:
> >>>
> >>> $ git remote remove local-daffodil-ncsa
> >>>
> >>> You should just be left with all the new tags/branches and your review
> >>> branches.
> >>>
> >>> Does that seem like a reasonable way to cutover without too much
> >>> disruption? I could turn this into a script that will do the cutover
> >>> automatically if that would make things easier?
> >>>
> >>> - Steve
> >>>
> >>> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
> >>>> This will be massively disruptive to me. I have like 7 or 8
> >> outstanding branches right now.
> >>>>
> >>>>
> >>>> How about we add the new tags and branches and leave the old ones
> there
> >> for now.
> >>>>
> >>>>
> >>>>
> >>>> ________________________________
> >>>> From: Steve Lawrence <sl...@apache.org>
> >>>> Sent: Tuesday, October 24, 2017 11:48:35 AM
> >>>> To: dev@daffodil.apache.org
> >>>> Subject: Import of Code to ASF Infrastructure
> >>>>
> >>>> An issue came up on the Apache Legal bug tracker that has a similar
> >>>> situation to ours.
> >>>>
> >>>> https://issues.apache.org/jira/browse/LEGAL-339
> >>>>
> >>>> Apache Heron is in a similar stage to us in incubation. They are
> working
> >>>> to transition over to the ASF infrastructure. Their original code is
> >>>> under a permissive license (Apache v2), but they do not have SGAs in
> >>>> place yet, and they wanted to know if they could import their code to
> >>>> ASF. The result of the issue is that since the code is under a
> >>>> permissive license, it is okay to import the code to the ASF git, and
> >>>> just not change any license headers yet. Once the remaining SGAs are
> in
> >>>> place we can change the headers. We can even do releases, but it will
> >>>> prevent graduation, but I suspect we'll have SGAs in place before our
> >>>> first ASF release.
> >>>>
> >>>> Related, I was thinking that if we were to do it, now would be a good
> >>>> time to rename all the old branches and tags to use the new Branch &
> Tag
> >>>> workflow [1] so that all future tags/branch are consistent with the
> old.
> >>>> This would just mean that all rc/alpha tags would have a 'v' prepended
> >>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g.
> 1.0.0
> >>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
> >>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
> >>>> change what the tags/branches point to, just changes their names.
> >>>>
> >>>> Since this would mean the tags change (which git tends to avoid), this
> >>>> will mean that we should all clone the new repo and work out of that,
> no
> >>>> longer using our old clones. This will ensure no old tags stick
> around.
> >>>> For any ongoing work, something like git format-patch would be a good
> >>>> method to get the changes to the new repo.
> >>>>
> >>>> Any thoughts/concerns with this?
> >>>>
> >>>> - Steve
> >>>>
> >>>>
> >>>> [1]
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>
Re: Import of Code to ASF Infrastructure
Posted by Steve Lawrence <sl...@apache.org>.
It looks like someone has already created an empty repo for us:
https://git-wip-us.apache.org/repos/asf?p=incubator-daffodil.git
And the github mirror:
https://github.com/apache/incubator-daffodil
I haven't tried pushing anything yet so I'm not sure if we have permissions.
- Steve
On 10/25/2017 08:04 AM, John D. Ament wrote:
> All,
>
> Do you want to aim to get a repo created on the ASF side?
>
> John
>
> On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence <sl...@apache.org> wrote:
>
>> Yes, branches/tags are essentially renamed. All commit hashes stay the
>> same. I've made the changes and pushed a test repo to my github:
>>
>> https://github.com/stevedlawrence/daffodil-new.git
>>
>> If you want to test this, you should be able to add this as a new remote
>> and see the new branch names/tags.
>>
>> This renames all version branches to 'support/vN.N.x', all release tags
>> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also now
>> signed in accordance with the tag/branch workflow.
>>
>> If this looks good, I can push it to the ASF repo and we can start
>> transitioning to that + github for the new workflow.
>>
>> - Steve
>>
>> On 10/25/2017 01:26 AM, Mike Beckerle wrote:
>>> So branches can just be renamed right?
>>>
>>> What I care about is the branches and the commit hashes. If those are
>> preserved, then the tags don't matter much to me.
>>>
>>>
>>>
>>> -------- Original message --------
>>> From: Steve Lawrence <sl...@apache.org>
>>> Date: 10/24/17 12:01 PM (GMT-07:00)
>>> To: dev@daffodil.apache.org, Mike Beckerle <mb...@tresys.com>
>>> Subject: Re: Import of Code to ASF Infrastructure
>>>
>>> The problem is you really can't delete tags in git, so now is really the
>>> best time to do it since we're moving repos.
>>>
>>> Is the disruption having to move your local review branches from one
>>> repo to another? If so, I think I found a decent solution to make a
>>> clean cut over with just a handful of commands:
>>>
>>> Make sure all your changes are committed to a review branch in your old
>>> repo. Move your current repo to a backup location:
>>>
>>> $ mv daffodil.git daffodil-ncsa.git
>>>
>>> Now clone the ASF git repo that will contain only the new tags/branches,
>>> this will be the new git repo:
>>>
>>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
>>> $ cd daffodil.git
>>>
>>> Add your local backup daffodil NCSA repo as a remote, specifying no tags
>>> and all the review branches you want via the -t option. There should be
>>> one -t option for each branch:
>>>
>>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
>>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
>>> $ git fetch local-daffodil-ncsa
>>>
>>> Create a local branch for each of the fetched review branches:
>>>
>>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
>>> -f2` $BRANCH; done
>>>
>>> Now remove the old local-daffodil-ncsa remote:
>>>
>>> $ git remote remove local-daffodil-ncsa
>>>
>>> You should just be left with all the new tags/branches and your review
>>> branches.
>>>
>>> Does that seem like a reasonable way to cutover without too much
>>> disruption? I could turn this into a script that will do the cutover
>>> automatically if that would make things easier?
>>>
>>> - Steve
>>>
>>> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
>>>> This will be massively disruptive to me. I have like 7 or 8
>> outstanding branches right now.
>>>>
>>>>
>>>> How about we add the new tags and branches and leave the old ones there
>> for now.
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> From: Steve Lawrence <sl...@apache.org>
>>>> Sent: Tuesday, October 24, 2017 11:48:35 AM
>>>> To: dev@daffodil.apache.org
>>>> Subject: Import of Code to ASF Infrastructure
>>>>
>>>> An issue came up on the Apache Legal bug tracker that has a similar
>>>> situation to ours.
>>>>
>>>> https://issues.apache.org/jira/browse/LEGAL-339
>>>>
>>>> Apache Heron is in a similar stage to us in incubation. They are working
>>>> to transition over to the ASF infrastructure. Their original code is
>>>> under a permissive license (Apache v2), but they do not have SGAs in
>>>> place yet, and they wanted to know if they could import their code to
>>>> ASF. The result of the issue is that since the code is under a
>>>> permissive license, it is okay to import the code to the ASF git, and
>>>> just not change any license headers yet. Once the remaining SGAs are in
>>>> place we can change the headers. We can even do releases, but it will
>>>> prevent graduation, but I suspect we'll have SGAs in place before our
>>>> first ASF release.
>>>>
>>>> Related, I was thinking that if we were to do it, now would be a good
>>>> time to rename all the old branches and tags to use the new Branch & Tag
>>>> workflow [1] so that all future tags/branch are consistent with the old.
>>>> This would just mean that all rc/alpha tags would have a 'v' prepended
>>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
>>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
>>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
>>>> change what the tags/branches point to, just changes their names.
>>>>
>>>> Since this would mean the tags change (which git tends to avoid), this
>>>> will mean that we should all clone the new repo and work out of that, no
>>>> longer using our old clones. This will ensure no old tags stick around.
>>>> For any ongoing work, something like git format-patch would be a good
>>>> method to get the changes to the new repo.
>>>>
>>>> Any thoughts/concerns with this?
>>>>
>>>> - Steve
>>>>
>>>>
>>>> [1]
>>>>
>> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
>>>>
>>>
>>>
>>
>>
>
Re: Import of Code to ASF Infrastructure
Posted by "John D. Ament" <jo...@apache.org>.
All,
Do you want to aim to get a repo created on the ASF side?
John
On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence <sl...@apache.org> wrote:
> Yes, branches/tags are essentially renamed. All commit hashes stay the
> same. I've made the changes and pushed a test repo to my github:
>
> https://github.com/stevedlawrence/daffodil-new.git
>
> If you want to test this, you should be able to add this as a new remote
> and see the new branch names/tags.
>
> This renames all version branches to 'support/vN.N.x', all release tags
> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also now
> signed in accordance with the tag/branch workflow.
>
> If this looks good, I can push it to the ASF repo and we can start
> transitioning to that + github for the new workflow.
>
> - Steve
>
> On 10/25/2017 01:26 AM, Mike Beckerle wrote:
> > So branches can just be renamed right?
> >
> > What I care about is the branches and the commit hashes. If those are
> preserved, then the tags don't matter much to me.
> >
> >
> >
> > -------- Original message --------
> > From: Steve Lawrence <sl...@apache.org>
> > Date: 10/24/17 12:01 PM (GMT-07:00)
> > To: dev@daffodil.apache.org, Mike Beckerle <mb...@tresys.com>
> > Subject: Re: Import of Code to ASF Infrastructure
> >
> > The problem is you really can't delete tags in git, so now is really the
> > best time to do it since we're moving repos.
> >
> > Is the disruption having to move your local review branches from one
> > repo to another? If so, I think I found a decent solution to make a
> > clean cut over with just a handful of commands:
> >
> > Make sure all your changes are committed to a review branch in your old
> > repo. Move your current repo to a backup location:
> >
> > $ mv daffodil.git daffodil-ncsa.git
> >
> > Now clone the ASF git repo that will contain only the new tags/branches,
> > this will be the new git repo:
> >
> > $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
> > $ cd daffodil.git
> >
> > Add your local backup daffodil NCSA repo as a remote, specifying no tags
> > and all the review branches you want via the -t option. There should be
> > one -t option for each branch:
> >
> > $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
> > review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
> > $ git fetch local-daffodil-ncsa
> >
> > Create a local branch for each of the fetched review branches:
> >
> > $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
> > -f2` $BRANCH; done
> >
> > Now remove the old local-daffodil-ncsa remote:
> >
> > $ git remote remove local-daffodil-ncsa
> >
> > You should just be left with all the new tags/branches and your review
> > branches.
> >
> > Does that seem like a reasonable way to cutover without too much
> > disruption? I could turn this into a script that will do the cutover
> > automatically if that would make things easier?
> >
> > - Steve
> >
> > On 10/24/2017 01:19 PM, Mike Beckerle wrote:
> >> This will be massively disruptive to me. I have like 7 or 8
> outstanding branches right now.
> >>
> >>
> >> How about we add the new tags and branches and leave the old ones there
> for now.
> >>
> >>
> >>
> >> ________________________________
> >> From: Steve Lawrence <sl...@apache.org>
> >> Sent: Tuesday, October 24, 2017 11:48:35 AM
> >> To: dev@daffodil.apache.org
> >> Subject: Import of Code to ASF Infrastructure
> >>
> >> An issue came up on the Apache Legal bug tracker that has a similar
> >> situation to ours.
> >>
> >> https://issues.apache.org/jira/browse/LEGAL-339
> >>
> >> Apache Heron is in a similar stage to us in incubation. They are working
> >> to transition over to the ASF infrastructure. Their original code is
> >> under a permissive license (Apache v2), but they do not have SGAs in
> >> place yet, and they wanted to know if they could import their code to
> >> ASF. The result of the issue is that since the code is under a
> >> permissive license, it is okay to import the code to the ASF git, and
> >> just not change any license headers yet. Once the remaining SGAs are in
> >> place we can change the headers. We can even do releases, but it will
> >> prevent graduation, but I suspect we'll have SGAs in place before our
> >> first ASF release.
> >>
> >> Related, I was thinking that if we were to do it, now would be a good
> >> time to rename all the old branches and tags to use the new Branch & Tag
> >> workflow [1] so that all future tags/branch are consistent with the old.
> >> This would just mean that all rc/alpha tags would have a 'v' prepended
> >> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
> >> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
> >> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
> >> change what the tags/branches point to, just changes their names.
> >>
> >> Since this would mean the tags change (which git tends to avoid), this
> >> will mean that we should all clone the new repo and work out of that, no
> >> longer using our old clones. This will ensure no old tags stick around.
> >> For any ongoing work, something like git format-patch would be a good
> >> method to get the changes to the new repo.
> >>
> >> Any thoughts/concerns with this?
> >>
> >> - Steve
> >>
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
> >>
> >
> >
>
>
Re: Import of Code to ASF Infrastructure
Posted by Steve Lawrence <sl...@apache.org>.
Yes, branches/tags are essentially renamed. All commit hashes stay the
same. I've made the changes and pushed a test repo to my github:
https://github.com/stevedlawrence/daffodil-new.git
If you want to test this, you should be able to add this as a new remote
and see the new branch names/tags.
This renames all version branches to 'support/vN.N.x', all release tags
to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also now
signed in accordance with the tag/branch workflow.
If this looks good, I can push it to the ASF repo and we can start
transitioning to that + github for the new workflow.
- Steve
On 10/25/2017 01:26 AM, Mike Beckerle wrote:
> So branches can just be renamed right?
>
> What I care about is the branches and the commit hashes. If those are preserved, then the tags don't matter much to me.
>
>
>
> -------- Original message --------
> From: Steve Lawrence <sl...@apache.org>
> Date: 10/24/17 12:01 PM (GMT-07:00)
> To: dev@daffodil.apache.org, Mike Beckerle <mb...@tresys.com>
> Subject: Re: Import of Code to ASF Infrastructure
>
> The problem is you really can't delete tags in git, so now is really the
> best time to do it since we're moving repos.
>
> Is the disruption having to move your local review branches from one
> repo to another? If so, I think I found a decent solution to make a
> clean cut over with just a handful of commands:
>
> Make sure all your changes are committed to a review branch in your old
> repo. Move your current repo to a backup location:
>
> $ mv daffodil.git daffodil-ncsa.git
>
> Now clone the ASF git repo that will contain only the new tags/branches,
> this will be the new git repo:
>
> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
> $ cd daffodil.git
>
> Add your local backup daffodil NCSA repo as a remote, specifying no tags
> and all the review branches you want via the -t option. There should be
> one -t option for each branch:
>
> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
> $ git fetch local-daffodil-ncsa
>
> Create a local branch for each of the fetched review branches:
>
> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
> -f2` $BRANCH; done
>
> Now remove the old local-daffodil-ncsa remote:
>
> $ git remote remove local-daffodil-ncsa
>
> You should just be left with all the new tags/branches and your review
> branches.
>
> Does that seem like a reasonable way to cutover without too much
> disruption? I could turn this into a script that will do the cutover
> automatically if that would make things easier?
>
> - Steve
>
> On 10/24/2017 01:19 PM, Mike Beckerle wrote:
>> This will be massively disruptive to me. I have like 7 or 8 outstanding branches right now.
>>
>>
>> How about we add the new tags and branches and leave the old ones there for now.
>>
>>
>>
>> ________________________________
>> From: Steve Lawrence <sl...@apache.org>
>> Sent: Tuesday, October 24, 2017 11:48:35 AM
>> To: dev@daffodil.apache.org
>> Subject: Import of Code to ASF Infrastructure
>>
>> An issue came up on the Apache Legal bug tracker that has a similar
>> situation to ours.
>>
>> https://issues.apache.org/jira/browse/LEGAL-339
>>
>> Apache Heron is in a similar stage to us in incubation. They are working
>> to transition over to the ASF infrastructure. Their original code is
>> under a permissive license (Apache v2), but they do not have SGAs in
>> place yet, and they wanted to know if they could import their code to
>> ASF. The result of the issue is that since the code is under a
>> permissive license, it is okay to import the code to the ASF git, and
>> just not change any license headers yet. Once the remaining SGAs are in
>> place we can change the headers. We can even do releases, but it will
>> prevent graduation, but I suspect we'll have SGAs in place before our
>> first ASF release.
>>
>> Related, I was thinking that if we were to do it, now would be a good
>> time to rename all the old branches and tags to use the new Branch & Tag
>> workflow [1] so that all future tags/branch are consistent with the old.
>> This would just mean that all rc/alpha tags would have a 'v' prepended
>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
>> change what the tags/branches point to, just changes their names.
>>
>> Since this would mean the tags change (which git tends to avoid), this
>> will mean that we should all clone the new repo and work out of that, no
>> longer using our old clones. This will ensure no old tags stick around.
>> For any ongoing work, something like git format-patch would be a good
>> method to get the changes to the new repo.
>>
>> Any thoughts/concerns with this?
>>
>> - Steve
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
>>
>
>
Re: Import of Code to ASF Infrastructure
Posted by Mike Beckerle <mb...@tresys.com>.
So branches can just be renamed right?
What I care about is the branches and the commit hashes. If those are preserved, then the tags don't matter much to me.
-------- Original message --------
From: Steve Lawrence <sl...@apache.org>
Date: 10/24/17 12:01 PM (GMT-07:00)
To: dev@daffodil.apache.org, Mike Beckerle <mb...@tresys.com>
Subject: Re: Import of Code to ASF Infrastructure
The problem is you really can't delete tags in git, so now is really the
best time to do it since we're moving repos.
Is the disruption having to move your local review branches from one
repo to another? If so, I think I found a decent solution to make a
clean cut over with just a handful of commands:
Make sure all your changes are committed to a review branch in your old
repo. Move your current repo to a backup location:
$ mv daffodil.git daffodil-ncsa.git
Now clone the ASF git repo that will contain only the new tags/branches,
this will be the new git repo:
$ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
$ cd daffodil.git
Add your local backup daffodil NCSA repo as a remote, specifying no tags
and all the review branches you want via the -t option. There should be
one -t option for each branch:
$ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
$ git fetch local-daffodil-ncsa
Create a local branch for each of the fetched review branches:
$ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
-f2` $BRANCH; done
Now remove the old local-daffodil-ncsa remote:
$ git remote remove local-daffodil-ncsa
You should just be left with all the new tags/branches and your review
branches.
Does that seem like a reasonable way to cutover without too much
disruption? I could turn this into a script that will do the cutover
automatically if that would make things easier?
- Steve
On 10/24/2017 01:19 PM, Mike Beckerle wrote:
> This will be massively disruptive to me. I have like 7 or 8 outstanding branches right now.
>
>
> How about we add the new tags and branches and leave the old ones there for now.
>
>
>
> ________________________________
> From: Steve Lawrence <sl...@apache.org>
> Sent: Tuesday, October 24, 2017 11:48:35 AM
> To: dev@daffodil.apache.org
> Subject: Import of Code to ASF Infrastructure
>
> An issue came up on the Apache Legal bug tracker that has a similar
> situation to ours.
>
> https://issues.apache.org/jira/browse/LEGAL-339
>
> Apache Heron is in a similar stage to us in incubation. They are working
> to transition over to the ASF infrastructure. Their original code is
> under a permissive license (Apache v2), but they do not have SGAs in
> place yet, and they wanted to know if they could import their code to
> ASF. The result of the issue is that since the code is under a
> permissive license, it is okay to import the code to the ASF git, and
> just not change any license headers yet. Once the remaining SGAs are in
> place we can change the headers. We can even do releases, but it will
> prevent graduation, but I suspect we'll have SGAs in place before our
> first ASF release.
>
> Related, I was thinking that if we were to do it, now would be a good
> time to rename all the old branches and tags to use the new Branch & Tag
> workflow [1] so that all future tags/branch are consistent with the old.
> This would just mean that all rc/alpha tags would have a 'v' prepended
> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
> change what the tags/branches point to, just changes their names.
>
> Since this would mean the tags change (which git tends to avoid), this
> will mean that we should all clone the new repo and work out of that, no
> longer using our old clones. This will ensure no old tags stick around.
> For any ongoing work, something like git format-patch would be a good
> method to get the changes to the new repo.
>
> Any thoughts/concerns with this?
>
> - Steve
>
>
> [1]
> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
>
Re: Import of Code to ASF Infrastructure
Posted by Steve Lawrence <sl...@apache.org>.
The problem is you really can't delete tags in git, so now is really the
best time to do it since we're moving repos.
Is the disruption having to move your local review branches from one
repo to another? If so, I think I found a decent solution to make a
clean cut over with just a handful of commands:
Make sure all your changes are committed to a review branch in your old
repo. Move your current repo to a backup location:
$ mv daffodil.git daffodil-ncsa.git
Now clone the ASF git repo that will contain only the new tags/branches,
this will be the new git repo:
$ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git
$ cd daffodil.git
Add your local backup daffodil NCSA repo as a remote, specifying no tags
and all the review branches you want via the -t option. There should be
one -t option for each branch:
$ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t
review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/
$ git fetch local-daffodil-ncsa
Create a local branch for each of the fetched review branches:
$ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut -d/
-f2` $BRANCH; done
Now remove the old local-daffodil-ncsa remote:
$ git remote remove local-daffodil-ncsa
You should just be left with all the new tags/branches and your review
branches.
Does that seem like a reasonable way to cutover without too much
disruption? I could turn this into a script that will do the cutover
automatically if that would make things easier?
- Steve
On 10/24/2017 01:19 PM, Mike Beckerle wrote:
> This will be massively disruptive to me. I have like 7 or 8 outstanding branches right now.
>
>
> How about we add the new tags and branches and leave the old ones there for now.
>
>
>
> ________________________________
> From: Steve Lawrence <sl...@apache.org>
> Sent: Tuesday, October 24, 2017 11:48:35 AM
> To: dev@daffodil.apache.org
> Subject: Import of Code to ASF Infrastructure
>
> An issue came up on the Apache Legal bug tracker that has a similar
> situation to ours.
>
> https://issues.apache.org/jira/browse/LEGAL-339
>
> Apache Heron is in a similar stage to us in incubation. They are working
> to transition over to the ASF infrastructure. Their original code is
> under a permissive license (Apache v2), but they do not have SGAs in
> place yet, and they wanted to know if they could import their code to
> ASF. The result of the issue is that since the code is under a
> permissive license, it is okay to import the code to the ASF git, and
> just not change any license headers yet. Once the remaining SGAs are in
> place we can change the headers. We can even do releases, but it will
> prevent graduation, but I suspect we'll have SGAs in place before our
> first ASF release.
>
> Related, I was thinking that if we were to do it, now would be a good
> time to rename all the old branches and tags to use the new Branch & Tag
> workflow [1] so that all future tags/branch are consistent with the old.
> This would just mean that all rc/alpha tags would have a 'v' prepended
> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the
> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
> change what the tags/branches point to, just changes their names.
>
> Since this would mean the tags change (which git tends to avoid), this
> will mean that we should all clone the new repo and work out of that, no
> longer using our old clones. This will ensure no old tags stick around.
> For any ongoing work, something like git format-patch would be a good
> method to get the changes to the new repo.
>
> Any thoughts/concerns with this?
>
> - Steve
>
>
> [1]
> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow
>
Re: Import of Code to ASF Infrastructure
Posted by Mike Beckerle <mb...@tresys.com>.
This will be massively disruptive to me. I have like 7 or 8 outstanding branches right now.
How about we add the new tags and branches and leave the old ones there for now.
________________________________
From: Steve Lawrence <sl...@apache.org>
Sent: Tuesday, October 24, 2017 11:48:35 AM
To: dev@daffodil.apache.org
Subject: Import of Code to ASF Infrastructure
An issue came up on the Apache Legal bug tracker that has a similar
situation to ours.
https://issues.apache.org/jira/browse/LEGAL-339
Apache Heron is in a similar stage to us in incubation. They are working
to transition over to the ASF infrastructure. Their original code is
under a permissive license (Apache v2), but they do not have SGAs in
place yet, and they wanted to know if they could import their code to
ASF. The result of the issue is that since the code is under a
permissive license, it is okay to import the code to the ASF git, and
just not change any license headers yet. Once the remaining SGAs are in
place we can change the headers. We can even do releases, but it will
prevent graduation, but I suspect we'll have SGAs in place before our
first ASF release.
Related, I was thinking that if we were to do it, now would be a good
time to rename all the old branches and tags to use the new Branch & Tag
workflow [1] so that all future tags/branch are consistent with the old.
This would just mean that all rc/alpha tags would have a 'v' prepended
(e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. 1.0.0
-> rel/v1.0.0), and all branches have a 'support/v' prepended and the
last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't
change what the tags/branches point to, just changes their names.
Since this would mean the tags change (which git tends to avoid), this
will mean that we should all clone the new repo and work out of that, no
longer using our old clones. This will ensure no old tags stick around.
For any ongoing work, something like git format-patch would be a good
method to get the changes to the new repo.
Any thoughts/concerns with this?
- Steve
[1]
https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow