Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Robert Munteanu]

On Mon, 2017-10-23 at 23:38 +0200, Robert Munteanu wrote:
> On Mon, 2017-10-23 at 18:40 +0100, Ian Boston wrote:
> > > So that would mean that all link to trunk would result in a 404
> > > Not
> > > Found, as I have tried it with [1].
> > >  So we either
> > > a) break all links to the 'trunk' branch, or
> > > b) leave the 'trunk' branch alive, with the added disadvantage
> > > that
> > > navigating from a 'trunk' link leaves the impression that the
> > > branch/repo are still in use.
> > > Did I get this right or is there something else?
> > 
> > yes. a) isnt very friendly.
> > 
> > If we choose b) we could rename the repository to sling-svn-ending-
> > 2017-10
> > or something like that. GitHub will redirect all traffic.
> > 
> > https://help.github.com/articles/renaming-a-repository/
> 
> That's pretty cool. I would assume that we won't be able to reclaim
> the
> old 'sling' name, otherwise the redirects would not work, but this
> should make it even clearer.
> 
> Robert

I tried to summarize the current discussion at 

  https://issues.apache.org/jira/browse/SLING-7183

I won't be able to look into this for the next two weeks, so if anyone
has the time to push this to its conclusion, feel free to do so.

Thanks,

Robert

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Robert Munteanu]

On Mon, 2017-10-23 at 18:40 +0100, Ian Boston wrote:
> > So that would mean that all link to trunk would result in a 404 Not
> > Found, as I have tried it with [1].
> 
> >  So we either
> 
> > a) break all links to the 'trunk' branch, or
> > b) leave the 'trunk' branch alive, with the added disadvantage that
> > navigating from a 'trunk' link leaves the impression that the
> > branch/repo are still in use.
> 
> > Did I get this right or is there something else?
> 
> yes. a) isnt very friendly.
> 
> If we choose b) we could rename the repository to sling-svn-ending-
> 2017-10
> or something like that. GitHub will redirect all traffic.
> 
> https://help.github.com/articles/renaming-a-repository/

That's pretty cool. I would assume that we won't be able to reclaim the
old 'sling' name, otherwise the redirects would not work, but this
should make it even clearer.

Robert

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Ian Boston]

Hi

> So that would mean that all link to trunk would result in a 404 Not
> Found, as I have tried it with [1].

>  So we either

> a) break all links to the 'trunk' branch, or
> b) leave the 'trunk' branch alive, with the added disadvantage that
> navigating from a 'trunk' link leaves the impression that the
> branch/repo are still in use.

> Did I get this right or is there something else?

yes. a) isnt very friendly.

If we choose b) we could rename the repository to sling-svn-ending-2017-10
or something like that. GitHub will redirect all traffic.

https://help.github.com/articles/renaming-a-repository/

The other option is to transfer ownership of the repository. Git will also
redirect.

https://help.github.com/articles/about-repository-transfers/


Best Regards
Ian


On 23 October 2017 at 13:48, Robert Munteanu  wrote:

> On Sun, 2017-10-22 at 15:28 +0100, Ian Boston wrote:
> > Hi,
> > Good solution. One small modification to help anyone get to the old
> > tree.
>
> Well, I saw what we did at Adobe last time we had something similar :-)
>
> >
> > Rather than switching the main branch and making it empty,  if you
> > branch
> > trunk to a new branch "archive" and then make trunk empty as you
> > suggest,
> > it will be possible to point anyone who gets a 404 to the new
> > "archive"
> > branch. Tagging the last commit from SVN would also help keep a
> > permanent
> > record.
> >
> > Only those URLs that are not pointing to a commit/tag/branch (other
> > than
> > trunk) will be broken and the README left in trunk can explain how to
> > change the URL.
>
> I think that there are plenty of links pointing to 'trunk' though. I
> have tried to make permanent links to github, but I did not do that all
> the time.
>
> So that would mean that all link to trunk would result in a 404 Not
> Found, as I have tried it with [1].
>
> So we either
>
> a) break all links to the 'trunk' branch, or
> b) leave the 'trunk' branch alive, with the added disadvantage that
> navigating from a 'trunk' link leaves the impression that the
> branch/repo are still in use.
>
> Did I get this right or is there something else?
>
> Robert
>
> [1]: https://github.com/apache/sling/blob/archived/KEYS
>

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Robert Munteanu]

On Sun, 2017-10-22 at 15:28 +0100, Ian Boston wrote:
> Hi,
> Good solution. One small modification to help anyone get to the old
> tree.

Well, I saw what we did at Adobe last time we had something similar :-)

> 
> Rather than switching the main branch and making it empty,  if you
> branch
> trunk to a new branch "archive" and then make trunk empty as you
> suggest,
> it will be possible to point anyone who gets a 404 to the new
> "archive"
> branch. Tagging the last commit from SVN would also help keep a
> permanent
> record.
> 
> Only those URLs that are not pointing to a commit/tag/branch (other
> than
> trunk) will be broken and the README left in trunk can explain how to
> change the URL.

I think that there are plenty of links pointing to 'trunk' though. I
have tried to make permanent links to github, but I did not do that all
the time.

So that would mean that all link to trunk would result in a 404 Not
Found, as I have tried it with [1].

So we either

a) break all links to the 'trunk' branch, or
b) leave the 'trunk' branch alive, with the added disadvantage that
navigating from a 'trunk' link leaves the impression that the
branch/repo are still in use.

Did I get this right or is there something else?

Robert

[1]: https://github.com/apache/sling/blob/archived/KEYS

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Ian Boston]

Hi,
Good solution. One small modification to help anyone get to the old tree.

Rather than switching the main branch and making it empty,  if you branch
trunk to a new branch "archive" and then make trunk empty as you suggest,
it will be possible to point anyone who gets a 404 to the new "archive"
branch. Tagging the last commit from SVN would also help keep a permanent
record.

Only those URLs that are not pointing to a commit/tag/branch (other than
trunk) will be broken and the README left in trunk can explain how to
change the URL.

Best Regards
Ian

On 22 October 2017 at 14:08, Justin Edelson 
wrote:

> +1
>
> Great solution.
> On Sat, Oct 21, 2017 at 3:26 PM Robert Munteanu 
> wrote:
>
> > On Fri, 2017-10-20 at 23:19 +0200, Robert Munteanu wrote:
> > > I guess the 'minimal damage' approach would be to switch the main
> > > branch and make that empty, with just a README.md .
> > >
> > > Would need to talk to infra to see how that can happen. Unless anyone
> > > is opposed, I would create a branch called 'archived' with the
> > > following README.md contents:
> >
> > Here's how it would look once switched:
> >
> >   https://github.com/apache/sling/tree/archived
> >
> > Robert
> >
>

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Justin Edelson]

+1

Great solution.
On Sat, Oct 21, 2017 at 3:26 PM Robert Munteanu  wrote:

> On Fri, 2017-10-20 at 23:19 +0200, Robert Munteanu wrote:
> > I guess the 'minimal damage' approach would be to switch the main
> > branch and make that empty, with just a README.md .
> >
> > Would need to talk to infra to see how that can happen. Unless anyone
> > is opposed, I would create a branch called 'archived' with the
> > following README.md contents:
>
> Here's how it would look once switched:
>
>   https://github.com/apache/sling/tree/archived
>
> Robert
>

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Robert Munteanu]

On Fri, 2017-10-20 at 23:19 +0200, Robert Munteanu wrote:
> I guess the 'minimal damage' approach would be to switch the main
> branch and make that empty, with just a README.md .
> 
> Would need to talk to infra to see how that can happen. Unless anyone
> is opposed, I would create a branch called 'archived' with the
> following README.md contents:

Here's how it would look once switched:

  https://github.com/apache/sling/tree/archived

Robert

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Robert Munteanu]

I guess the 'minimal damage' approach would be to switch the main
branch and make that empty, with just a README.md .

Would need to talk to infra to see how that can happen. Unless anyone
is opposed, I would create a branch called 'archived' with the
following README.md contents:

8<---

# Apache Sling main repository (obsolete)

This repository used to contain the Apache Sling git mirror. With the
[migration to Git](https://issues.apache.org/jira/browse/SLING-3987)
the content represents and older state and should not be relied upon.

This repository is still kept to prevent broken links from various
sites to pull requests or commits.

Please do not open pull requests, they will be ignored.

For more information about the Apache Sling source repositories, see
the [project information](https://sling.apache.org/project-information.
html#source-repository).

8<---

Thoughts?

Robert

On Fri, 2017-10-20 at 12:45 +0100, Ian Boston wrote:
> Hi,
> I can think of at least one non public Jira whose links will break.
> Archiving probably wont work as most links point to a line number,
> commit,
> or something specific.
> 
> I guess we could just say tough, its too much effort to fix, anyone
> really
> interested will find the information for themselves.
> 
> I see tomcat may have had the same issue. They just started a new
> repo for
> each major version and left the old one as is.
> Annother solution is to put a readme
> 
> 
> Also, when you delete the apache/sling repo IIRC someone who forked
> it will
> take over and all forks will point to them, or at least, thats what
> happend
> when I deleted one of my repos. From memory it was the repo at the
> top of
> the forks list [1] which seems to be [2], but it could be the first
> person
> to fork, if you have the patience to go back through githubs record
> of the
> network.
> 
> Best Regards
> Ian
> 
> 
> 1 https://github.com/apache/sling/network/members
> 2 https://github.com/447327642/sling
> 
> On 20 October 2017 at 12:11, Robert Munteanu 
> wrote:
> 
> > Hi Ian,
> > 
> > On Fri, 2017-10-20 at 11:04 +0100, Ian Boston wrote:
> > > BTW,
> > > Deleting github:apache/sling will 404 every reference to code
> > > there
> > > from
> > > JIRA in many places. Probably not a good idea to delete it, but
> > > it
> > > should
> > > be made readonly.
> > 
> > That's a good point, I did not consider this.
> > 
> > The problematic part of keeping the old sling repository around is
> > that
> > it is probably the entry point to many people.
> > 
> > So the way I see it we have:
> > 
> > 1. Keep the old 'sling' mirror on Github
> > 
> > + links are not broken
> > - content is duplicated and out of date
> > - no good entry point for users when they visit
> > github.com/apache/sling
> > 
> > 2. Remove the old sling-mirror
> > 
> > + good entry point for Sling source code ( can contains e.g. repo
> > script to pull down all Sling modules )
> > + no duplicate or out-of-date content
> > - links are broken
> > 
> > Additionally, we already have a gitbox 'sling' repository that is
> > not
> > mirrored to GitHub - https://gitbox.apache.org/repos/asf?p=sling.gi
> > t;a=
> > summary , which can add to the confusion. Yes, we can rename it so
> > it's
> > not a con per se, but wanted to point that out.
> > 
> > As usual, my proposal is scripting :-) I would write a Jira script
> > that
> > inspects all the Sling tickets, and when finding a link to the
> > github.com/apache/sling repo, I would edit the comment and add a
> > note
> > that the link is outdated.
> > 
> > Another alternative is to move the repo to github.com/apache/sling-
> > archive and tweak the links to point to that. What I don't really
> > like
> > about that is that we will have outdated content, which is
> > confusing.
> > Maybe we can talk to infra to move it _and_ change the default
> > branch
> > to something like 'archived'? This way we'll only get a README.md
> > which
> > says this repo is archived for historical purposes and we'll also
> > get
> > proper links if we edit the Jira comments.
> > 
> > My proposal would be to remove the 'old' sling repository, with
> > tweaking the Jira comments if we think it's worthwhile.
> > Alternatively,
> > we can consider archiving it, but that's going to take a bit longer
> > due
> > to the need to write a script and also asking infra for help with
> > the
> > move.
> > 
> > Thanks,
> > 
> > Robert
> > 

Re: What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Ian Boston]

Hi,
I can think of at least one non public Jira whose links will break.
Archiving probably wont work as most links point to a line number, commit,
or something specific.

I guess we could just say tough, its too much effort to fix, anyone really
interested will find the information for themselves.

I see tomcat may have had the same issue. They just started a new repo for
each major version and left the old one as is.
Annother solution is to put a readme


Also, when you delete the apache/sling repo IIRC someone who forked it will
take over and all forks will point to them, or at least, thats what happend
when I deleted one of my repos. From memory it was the repo at the top of
the forks list [1] which seems to be [2], but it could be the first person
to fork, if you have the patience to go back through githubs record of the
network.

Best Regards
Ian


1 https://github.com/apache/sling/network/members
2 https://github.com/447327642/sling

On 20 October 2017 at 12:11, Robert Munteanu  wrote:

> Hi Ian,
>
> On Fri, 2017-10-20 at 11:04 +0100, Ian Boston wrote:
> > BTW,
> > Deleting github:apache/sling will 404 every reference to code there
> > from
> > JIRA in many places. Probably not a good idea to delete it, but it
> > should
> > be made readonly.
>
> That's a good point, I did not consider this.
>
> The problematic part of keeping the old sling repository around is that
> it is probably the entry point to many people.
>
> So the way I see it we have:
>
> 1. Keep the old 'sling' mirror on Github
>
> + links are not broken
> - content is duplicated and out of date
> - no good entry point for users when they visit github.com/apache/sling
>
> 2. Remove the old sling-mirror
>
> + good entry point for Sling source code ( can contains e.g. repo
> script to pull down all Sling modules )
> + no duplicate or out-of-date content
> - links are broken
>
> Additionally, we already have a gitbox 'sling' repository that is not
> mirrored to GitHub - https://gitbox.apache.org/repos/asf?p=sling.git;a=
> summary , which can add to the confusion. Yes, we can rename it so it's
> not a con per se, but wanted to point that out.
>
> As usual, my proposal is scripting :-) I would write a Jira script that
> inspects all the Sling tickets, and when finding a link to the
> github.com/apache/sling repo, I would edit the comment and add a note
> that the link is outdated.
>
> Another alternative is to move the repo to github.com/apache/sling-
> archive and tweak the links to point to that. What I don't really like
> about that is that we will have outdated content, which is confusing.
> Maybe we can talk to infra to move it _and_ change the default branch
> to something like 'archived'? This way we'll only get a README.md which
> says this repo is archived for historical purposes and we'll also get
> proper links if we edit the Jira comments.
>
> My proposal would be to remove the 'old' sling repository, with
> tweaking the Jira comments if we think it's worthwhile. Alternatively,
> we can consider archiving it, but that's going to take a bit longer due
> to the need to write a script and also asking infra for help with the
> move.
>
> Thanks,
>
> Robert
>

What to do with github.com/apache/sling (was [git] Migration to git repositories sort of complete)

[Robert Munteanu]

Hi Ian,

On Fri, 2017-10-20 at 11:04 +0100, Ian Boston wrote:
> BTW,
> Deleting github:apache/sling will 404 every reference to code there
> from
> JIRA in many places. Probably not a good idea to delete it, but it
> should
> be made readonly.

That's a good point, I did not consider this. 

The problematic part of keeping the old sling repository around is that
it is probably the entry point to many people.

So the way I see it we have:

1. Keep the old 'sling' mirror on Github

+ links are not broken
- content is duplicated and out of date
- no good entry point for users when they visit github.com/apache/sling

2. Remove the old sling-mirror

+ good entry point for Sling source code ( can contains e.g. repo
script to pull down all Sling modules )
+ no duplicate or out-of-date content
- links are broken

Additionally, we already have a gitbox 'sling' repository that is not
mirrored to GitHub - https://gitbox.apache.org/repos/asf?p=sling.git;a=
summary , which can add to the confusion. Yes, we can rename it so it's
not a con per se, but wanted to point that out.

As usual, my proposal is scripting :-) I would write a Jira script that
inspects all the Sling tickets, and when finding a link to the
github.com/apache/sling repo, I would edit the comment and add a note
that the link is outdated.

Another alternative is to move the repo to github.com/apache/sling-
archive and tweak the links to point to that. What I don't really like
about that is that we will have outdated content, which is confusing.
Maybe we can talk to infra to move it _and_ change the default branch
to something like 'archived'? This way we'll only get a README.md which
says this repo is archived for historical purposes and we'll also get
proper links if we edit the Jira comments.

My proposal would be to remove the 'old' sling repository, with
tweaking the Jira comments if we think it's worthwhile. Alternatively,
we can consider archiving it, but that's going to take a bit longer due
to the need to write a script and also asking infra for help with the
move.

Thanks,

Robert