sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Klco <>
Subject Re: apache/sling as github landing repository
Date Fri, 26 Jan 2018 02:21:27 GMT
+1 this absolutely is there right approach for users

On Jan 25, 2018 3:54 PM, "Alexander Klimetschek" <>

Hi everyone,

after the move to github and source code modularization (cool), the
previous sling repository apache/sling [0] is now empty. Except for a
readme that currently mostly addresses active committers (few, experts that
know the context) rather than users of sling (many, newbies that see Sling
code for the first time). It was renamed to apache/sling-old-svn-mirror.
Old links – if they include a branch or revision will still work, including
trunk – which is good.

However, sling now doesn't have a good github "landing" repository anymore.
You know, a central place that tells you where to find the code, which is
now scattered across many repos, or that allows you to browse it without
knowing exactly what to search for.

Currently the very well hidden answers are [1] and [2], which aren't
obvious. When hitting apache/sling, you find a readme that links to the
project info page [3] that among many other links and lots of texts has a
link to [1], which is hard to find IMO and has too many steps.

Furthermore, [1] is not curated and depends on whatever result order sling
gives you. But it might be very useful to categorize the repos, say all
"resource resolver" related stuff, or extensions. Oliver Lietz built [5]
based on automatic processing of [2], but it's also not curated and hard to
find things if you don't know exactly how things are split up and named.

My humble suggestion would be:

1. restore the apache/sling named repo, since that should help with SEO and
"keeping" the existing brand

2. have a readme in there as the github landing page, just like any github
project nowadays, which should include an about project and most
information how to use sling/download it, find source repos and how to
build it. Similar to the project information page [3], but more easily
digestible with less text.

3. move the aggregator [2] to apache/sling, as that feels like a natural
place (since this all happens on the new "master" branch, there is no
conflict with the old sling code base in there)

4. have a curated list of repos in there (could be a separated markdown
prominently linked from the main readme given its size), which would
provide some categorization and e.g. start with the important stuff at the
top. Guidelines for creating new repos/changing repos should hint at
updating this readme. But even if it's not 100% up to date all the time,
the vast majority of repos that don't change over time will be explorable.


FYI, this was initially discussed on [4]. I was always looking at Sling
source code on github before, searching, reading, looking at the version
history, even when it was "just" a mirror of the svn. When you were only
reading, this didn't matter, and github's web view is so much better than
the svn web view. I believe many folks did the same. The switch now is a
bit of a break in that approach, if you can't easily find the source code



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message