You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@adobe.com.INVALID> on 2018/02/03 03:16:39 UTC
Re: apache/sling as github landing repository
On 31.01.2018, at 00:23, Robert Munteanu <ro...@apache.org> wrote:
> Links to commits and files from the old sling repo. For example
>
> * https://github.com/apache/sling/commit/368f5f9c9f6d4c0e2602065687d95e
> b173f94b85
> * https://github.com/apache/sling/blob/trunk/bundles/extensions/bundler
> esource/src/main/java/org/apache/sling/bundleresource/impl/BundleResour
> ce.java
>
> These would break if we add another 'sling' repo but work since we
> renamed 'sling' to 'sling-old-svn-mirror' and Github is adding
> redirects.
> […]
> Right, but it's not about conflicts, it's about breaking old links.
> Backwards compatiblity and all that :-)
Step 2 would include the old sling repo under apache/sling again, so that all links work (as discussed below).
> Actually that's not a bad idea :-) The only downside would be that
> cloning the repository would be really slow due to the large size. Not
> sure if we can work around it.
Then maybe it's ok to have the aggregator list in a different repo, prominently linked from apache/sling, and the sling one stays as just a landing page repo, with mostly manually curated markdown files. Where cloning a large repo is not such a big deal, as it would be on people's local computer and already cloned (unlike the aggregator which might be cloned a lot by CI tools and new users).
Cheers,
Alex
Re: apache/sling as github landing repository
Posted by Robert Munteanu <ro...@apache.org>.
Hi Jason,
On Sat, 2018-02-10 at 09:24 -0500, Jason E Bailey wrote:
> And this would be one of those occasions where I thought I knew what
> I was talking about and I was wrong. What I was referencing was
> something I was led to believe was submodules but is so convoluted
> that I don't want to go there. I can see where submodules would be
> really useful in some situations but from what I've been hearing on
> this conversation thread it's not a solution.
Thanks for coming back to the list, even if the answer is that there is
nothing to include in a POC :-)
For the record, one additional point to consider with the ASF-hosted
infrastructure is that for most cases only actual 'people' can commit,
not bots.
Infra is pretty strong in their stance in making sure that all check-
ins are validated from an IP point of view, and a bot writing in the
git repos, even though technically it does not add source code, would
need pretty strong arguments in the 'risk vs gain' area.
Robert
>
> - Jason
>
> On Thu, Feb 8, 2018, at 11:03 AM, Bertrand Delacretaz wrote:
> > On Thu, Feb 8, 2018 at 4:27 PM, Jason E Bailey <je...@apache.org>
> > wrote:
> > > I'll work on standing something up as a POC so that there is
> > > something tangible...
> >
> > Great, thanks!
> >
> > -Bertrand
Re: apache/sling as github landing repository
Posted by Jason E Bailey <je...@apache.org>.
And this would be one of those occasions where I thought I knew what I was talking about and I was wrong. What I was referencing was something I was led to believe was submodules but is so convoluted that I don't want to go there. I can see where submodules would be really useful in some situations but from what I've been hearing on this conversation thread it's not a solution.
- Jason
On Thu, Feb 8, 2018, at 11:03 AM, Bertrand Delacretaz wrote:
> On Thu, Feb 8, 2018 at 4:27 PM, Jason E Bailey <je...@apache.org> wrote:
> > I'll work on standing something up as a POC so that there is something tangible...
>
> Great, thanks!
>
> -Bertrand
Re: apache/sling as github landing repository
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Feb 8, 2018 at 4:27 PM, Jason E Bailey <je...@apache.org> wrote:
> I'll work on standing something up as a POC so that there is something tangible...
Great, thanks!
-Bertrand
Re: apache/sling as github landing repository
Posted by Jason E Bailey <je...@apache.org>.
I'll work on standing something up as a POC so that there is something tangible.
- Jason
On Thu, Feb 8, 2018, at 9:29 AM, Bertrand Delacretaz wrote:
> On Thu, Feb 8, 2018 at 2:25 PM, Jason E Bailey <je...@apache.org> wrote:
> > ...an aggregated view that just reflects the status of submodules...
>
> I'm +1 on at least experimenting with that if you can do it without
> too much effort.
>
> -Bertrand
Re: apache/sling as github landing repository
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Feb 8, 2018 at 2:25 PM, Jason E Bailey <je...@apache.org> wrote:
> ...an aggregated view that just reflects the status of submodules...
I'm +1 on at least experimenting with that if you can do it without
too much effort.
-Bertrand
Re: apache/sling as github landing repository
Posted by Jason E Bailey <je...@apache.org>.
Correct. That's exactly what I was trying to articulate, an aggregated view that just reflects the status of submodules.
- Jason
On Thu, Feb 8, 2018, at 4:15 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Thu, Feb 8, 2018 at 1:37 AM, Jason E Bailey <je...@apache.org> wrote:
> > ...In either case, you'd end up with a central location with a snapshot of
> > the latest code that is individually managed in it's own repo....
>
> IIUC this has no impact on the existing repositories, it's just an
> additional one that uses submodules and Jenkins to keep that
> aggregated snapshot mostly up to date?
>
> If yes I think that's interesting - I wouldn't want us to be too
> dependent on submodules, but if it's a distinct aggregated view that
> sounds useful.
>
> -Bertrand
Re: apache/sling as github landing repository
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Feb 8, 2018 at 1:37 AM, Jason E Bailey <je...@apache.org> wrote:
> ...In either case, you'd end up with a central location with a snapshot of
> the latest code that is individually managed in it's own repo....
IIUC this has no impact on the existing repositories, it's just an
additional one that uses submodules and Jenkins to keep that
aggregated snapshot mostly up to date?
If yes I think that's interesting - I wouldn't want us to be too
dependent on submodules, but if it's a distinct aggregated view that
sounds useful.
-Bertrand
Re: apache/sling as github landing repository
Posted by Jason E Bailey <je...@apache.org>.
What we have is a jenkinsFile so that, as part of the commit , it triggers the repository that's acting as the uber repository to update it's submodules. This could even be modified slightly so that a given submodule is only updated on it's release rather then every update.
In either case, you'd end up with a central location with a snapshot of the latest code that is individually managed in it's own repo.
the whole relying on github to grep multiple search result to try to determine the root repo is friction that isn't necessary.
- Jason
On Wed, Feb 7, 2018, at 6:10 PM, Alexander Klimetschek wrote:
> Git submodules don't work well in this situation, as the will point to a
> particular revision of the submodule. You'd have to constantly change
> the super repository whenever there was a commit in a submodule.
>
> Sling uses Android's repo for this purpose. The super repo is called
> sling-aggregator [0].
>
> A related tool we are using at our company is gitslave [1], which works
> ok. Usually it ends being used for tools such as source code audit or
> locale string extraction, that should see the entire code base. But
> human devs usually leverage github's search features to find code in
> individual repos if they don't know which repo yet.
>
> [0] https://github.com/apache/sling-aggregator
> [1] http://gitslave.sourceforge.net
>
> Cheers,
> Alex
>
> > On 05.02.2018, at 18:45, Jason E Bailey <je...@apache.org> wrote:
> >
> > Has there been any consideration of using git submodules to have a single git repository that reflects all the other repositories? It would allow for a central view, facilitate search, and still maintain a separation of the individual projects.
> >
> > - Jason
> >
> > On Fri, Feb 2, 2018, at 10:16 PM, Alexander Klimetschek wrote:
> >> On 31.01.2018, at 00:23, Robert Munteanu <ro...@apache.org> wrote:
> >>> Links to commits and files from the old sling repo. For example
> >>>
> >>> * https://github.com/apache/sling/commit/368f5f9c9f6d4c0e2602065687d95e
> >>> b173f94b85
> >>> * https://github.com/apache/sling/blob/trunk/bundles/extensions/bundler
> >>> esource/src/main/java/org/apache/sling/bundleresource/impl/BundleResour
> >>> ce.java
> >>>
> >>> These would break if we add another 'sling' repo but work since we
> >>> renamed 'sling' to 'sling-old-svn-mirror' and Github is adding
> >>> redirects.
> >>> […]
> >>> Right, but it's not about conflicts, it's about breaking old links.
> >>> Backwards compatiblity and all that :-)
> >>
> >> Step 2 would include the old sling repo under apache/sling again, so
> >> that all links work (as discussed below).
> >>
> >>> Actually that's not a bad idea :-) The only downside would be that
> >>> cloning the repository would be really slow due to the large size. Not
> >>> sure if we can work around it.
> >>
> >> Then maybe it's ok to have the aggregator list in a different repo,
> >> prominently linked from apache/sling, and the sling one stays as just a
> >> landing page repo, with mostly manually curated markdown files. Where
> >> cloning a large repo is not such a big deal, as it would be on people's
> >> local computer and already cloned (unlike the aggregator which might be
> >> cloned a lot by CI tools and new users).
> >>
> >> Cheers,
> >> Alex
>
Re: apache/sling as github landing repository
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
Git submodules don't work well in this situation, as the will point to a particular revision of the submodule. You'd have to constantly change the super repository whenever there was a commit in a submodule.
Sling uses Android's repo for this purpose. The super repo is called sling-aggregator [0].
A related tool we are using at our company is gitslave [1], which works ok. Usually it ends being used for tools such as source code audit or locale string extraction, that should see the entire code base. But human devs usually leverage github's search features to find code in individual repos if they don't know which repo yet.
[0] https://github.com/apache/sling-aggregator
[1] http://gitslave.sourceforge.net
Cheers,
Alex
> On 05.02.2018, at 18:45, Jason E Bailey <je...@apache.org> wrote:
>
> Has there been any consideration of using git submodules to have a single git repository that reflects all the other repositories? It would allow for a central view, facilitate search, and still maintain a separation of the individual projects.
>
> - Jason
>
> On Fri, Feb 2, 2018, at 10:16 PM, Alexander Klimetschek wrote:
>> On 31.01.2018, at 00:23, Robert Munteanu <ro...@apache.org> wrote:
>>> Links to commits and files from the old sling repo. For example
>>>
>>> * https://github.com/apache/sling/commit/368f5f9c9f6d4c0e2602065687d95e
>>> b173f94b85
>>> * https://github.com/apache/sling/blob/trunk/bundles/extensions/bundler
>>> esource/src/main/java/org/apache/sling/bundleresource/impl/BundleResour
>>> ce.java
>>>
>>> These would break if we add another 'sling' repo but work since we
>>> renamed 'sling' to 'sling-old-svn-mirror' and Github is adding
>>> redirects.
>>> […]
>>> Right, but it's not about conflicts, it's about breaking old links.
>>> Backwards compatiblity and all that :-)
>>
>> Step 2 would include the old sling repo under apache/sling again, so
>> that all links work (as discussed below).
>>
>>> Actually that's not a bad idea :-) The only downside would be that
>>> cloning the repository would be really slow due to the large size. Not
>>> sure if we can work around it.
>>
>> Then maybe it's ok to have the aggregator list in a different repo,
>> prominently linked from apache/sling, and the sling one stays as just a
>> landing page repo, with mostly manually curated markdown files. Where
>> cloning a large repo is not such a big deal, as it would be on people's
>> local computer and already cloned (unlike the aggregator which might be
>> cloned a lot by CI tools and new users).
>>
>> Cheers,
>> Alex
Re: apache/sling as github landing repository
Posted by Jason E Bailey <je...@apache.org>.
Has there been any consideration of using git submodules to have a single git repository that reflects all the other repositories? It would allow for a central view, facilitate search, and still maintain a separation of the individual projects.
- Jason
On Fri, Feb 2, 2018, at 10:16 PM, Alexander Klimetschek wrote:
> On 31.01.2018, at 00:23, Robert Munteanu <ro...@apache.org> wrote:
> > Links to commits and files from the old sling repo. For example
> >
> > * https://github.com/apache/sling/commit/368f5f9c9f6d4c0e2602065687d95e
> > b173f94b85
> > * https://github.com/apache/sling/blob/trunk/bundles/extensions/bundler
> > esource/src/main/java/org/apache/sling/bundleresource/impl/BundleResour
> > ce.java
> >
> > These would break if we add another 'sling' repo but work since we
> > renamed 'sling' to 'sling-old-svn-mirror' and Github is adding
> > redirects.
> > […]
> > Right, but it's not about conflicts, it's about breaking old links.
> > Backwards compatiblity and all that :-)
>
> Step 2 would include the old sling repo under apache/sling again, so
> that all links work (as discussed below).
>
> > Actually that's not a bad idea :-) The only downside would be that
> > cloning the repository would be really slow due to the large size. Not
> > sure if we can work around it.
>
> Then maybe it's ok to have the aggregator list in a different repo,
> prominently linked from apache/sling, and the sling one stays as just a
> landing page repo, with mostly manually curated markdown files. Where
> cloning a large repo is not such a big deal, as it would be on people's
> local computer and already cloned (unlike the aggregator which might be
> cloned a lot by CI tools and new users).
>
> Cheers,
> Alex
Re: Making github.com/apache/sling a git repo, moving away old svn
mirror (Re: apache/sling as github landing repository)
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
On 27.02.2018, at 22:07, Robert Munteanu <ro...@apache.org> wrote:
> IIUC the proposal was to import the old svn mirror as a git repo, and
> Betrand argued this would be a really large repo, and that's an
> impediment for something which would be heavily cloned.
You are right.
It could be two repos: the old one with all the old content and a new README landing page under the name apache/sling, and a separate apache/sling-aggregator which gets cloned and is lean. The landing page README can point to the aggregator repo.
Cheers,
Alex
Re: Making github.com/apache/sling a git repo, moving away old svn
mirror (Re: apache/sling as github landing repository)
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, 2018-02-15 at 20:57 +0000, Alexander Klimetschek wrote:
> On 12.02.2018, at 01:23, Robert Munteanu <ro...@apache.org> wrote:
> > The basic proposal as I see it would be to add a new 'sling' top-
> > level
> > github repo, which means that:
> >
> > 1. we control what goes in there - README.md most importantly
> > 2. old links to sling commits and files will be broken .
>
> No! It's absolutely not necessary to break the old links.
>
> If apache/sling is based on the "old" repo, and you are only adding
> new stuff on the "master" branch (which is new, as it was never used
> in the subversion based Sling), you don't have any conflicts.
>
> You can have your cake and eat it too in this case - that's what I am
> trying to say all the time :D It's just a matter of working with
> infra to copy things around and replace the github repo accordingly.
IIUC the proposal was to import the old svn mirror as a git repo, and
Betrand argued this would be a really large repo, and that's an
impediment for something which would be heavily cloned.
Robert
Re: Making github.com/apache/sling a git repo, moving away old svn
mirror (Re: apache/sling as github landing repository)
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
On 12.02.2018, at 01:23, Robert Munteanu <ro...@apache.org> wrote:
> The basic proposal as I see it would be to add a new 'sling' top-level
> github repo, which means that:
>
> 1. we control what goes in there - README.md most importantly
> 2. old links to sling commits and files will be broken .
No! It's absolutely not necessary to break the old links.
If apache/sling is based on the "old" repo, and you are only adding new stuff on the "master" branch (which is new, as it was never used in the subversion based Sling), you don't have any conflicts.
You can have your cake and eat it too in this case - that's what I am trying to say all the time :D It's just a matter of working with infra to copy things around and replace the github repo accordingly.
Cheers,
Alex
Re: Making github.com/apache/sling a git repo, moving away old svn
mirror (Re: apache/sling as github landing repository)
Posted by Daniel Klco <dk...@apache.org>.
+1
On Mon, Feb 12, 2018 at 4:25 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Mon, Feb 12, 2018 at 10:23 AM, Robert Munteanu <ro...@apache.org>
> wrote:
> > ...The basic proposal as I see it would be to add a new 'sling' top-level
> > github repo, which means that:
> >
> > 1. we control what goes in there - README.md most importantly
> > 2. old links to sling commits and files will be broken . ...
>
> +1
>
> -Bertrand
>
Re: Making github.com/apache/sling a git repo, moving away old svn
mirror (Re: apache/sling as github landing repository)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Feb 12, 2018 at 10:23 AM, Robert Munteanu <ro...@apache.org> wrote:
> ...The basic proposal as I see it would be to add a new 'sling' top-level
> github repo, which means that:
>
> 1. we control what goes in there - README.md most importantly
> 2. old links to sling commits and files will be broken . ...
+1
-Bertrand
Making github.com/apache/sling a git repo, moving away old svn
mirror (Re: apache/sling as github landing repository)
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
I usually am reluctant in revisiting old decisions, especially ones
that were so discussed, like this one. Some summaries of previous
discussion are at [1], [2] . But Alex makes some good points and after
the migration I think we should consider whether backwards
compatibility of incoming links is worth the limited control we have
over github.com/apache/sling, which many times is an entry point for
developers.
The basic proposal as I see it would be to add a new 'sling' top-level
github repo, which means that:
1. we control what goes in there - README.md most importantly
2. old links to sling commits and files will be broken .
TBH, I am not sure #2 is such a bad thing, given that I've seen people
still link to files in the old repo.
Thoughts?
Thanks,
Robert
[1]: https://lists.apache.org/thread.html/9e1ceee36af811ba3d2a0a2baa249
8077281f0d3c1da29747a833ea3@%3Cdev.sling.apache.org%3E
[2]: https://issues.apache.org/jira/browse/SLING-7183