Julian Foad
2018-12-07 10:50:04 UTC
(From my thoughts on svn community development: https://cwiki.apache.org/confluence/display/SVN/What%27s+In+My+Head#What'sInMyHead-Integratearchives/logs,permalinks,searching )
Problem: Past communications are scattered across systems and storage locations, with no consistent archives or permalinks, so cross-referencing is difficult and non-permanent. Our issue tracker and wiki provide only links that are tied to their current provider technology.
The types of information include:
Short-form chat (IRC) archives: Matrix-Static, irclogger, ASF Wilderness IRC logs.
Email/forum archives: haxx.se, ASF Pony Mail, the old Tigris lists. (The old Tigris mailing-lists system used to provide a permalink to the archived version at the bottom of each mail delivered.)
Issue Tracker: the current Jira issues, the old issuezilla.
Wiki pages: the current Confluence, the old MoinMoin.
An important step is to develop a URL "permalink" scheme to refer to our various resources. These would be technology-ignorant URLs, all under subversion.apache.org, like "/issue/1234".
A baby step is the '.message-ids.tsv' file in our web site directory, holding a mapping from haxx archive URLs used in our web pages to email message ids, with (in the commit log message) a script to generate it. There is, as yet, no automation to use the mapping in any way.
Initial tasks:
start documenting a URL-space map for our resources
populate one entry, e.g. "/issue/<number> → issue <number>"
implement some simple automated handling (e.g. redirects) for that
well, well... we already have this in our .htaccess which covers that exact case along with some aliases:
"RedirectMatch ^/issue[^A-Za-z0-9]?(\d+)$ https://issues.apache.org/jira/browse/SVN-$1"
start using it: update existing direct links to point here instead; publicize it
Deeper integration: A permalink URL should not merely redirect the user to its technology-specific target URL, but present the target in such a way that other inbound and outbound URLs also use the permalink form. With a big third-party system like Jira or Confluence the feasibility of that is going to depend entirely on whether the system has built-in support for that usage.
Problem: Past communications are scattered across systems and storage locations, with no consistent archives or permalinks, so cross-referencing is difficult and non-permanent. Our issue tracker and wiki provide only links that are tied to their current provider technology.
The types of information include:
Short-form chat (IRC) archives: Matrix-Static, irclogger, ASF Wilderness IRC logs.
Email/forum archives: haxx.se, ASF Pony Mail, the old Tigris lists. (The old Tigris mailing-lists system used to provide a permalink to the archived version at the bottom of each mail delivered.)
Issue Tracker: the current Jira issues, the old issuezilla.
Wiki pages: the current Confluence, the old MoinMoin.
An important step is to develop a URL "permalink" scheme to refer to our various resources. These would be technology-ignorant URLs, all under subversion.apache.org, like "/issue/1234".
A baby step is the '.message-ids.tsv' file in our web site directory, holding a mapping from haxx archive URLs used in our web pages to email message ids, with (in the commit log message) a script to generate it. There is, as yet, no automation to use the mapping in any way.
Initial tasks:
start documenting a URL-space map for our resources
populate one entry, e.g. "/issue/<number> → issue <number>"
implement some simple automated handling (e.g. redirects) for that
well, well... we already have this in our .htaccess which covers that exact case along with some aliases:
"RedirectMatch ^/issue[^A-Za-z0-9]?(\d+)$ https://issues.apache.org/jira/browse/SVN-$1"
start using it: update existing direct links to point here instead; publicize it
Deeper integration: A permalink URL should not merely redirect the user to its technology-specific target URL, but present the target in such a way that other inbound and outbound URLs also use the permalink form. With a big third-party system like Jira or Confluence the feasibility of that is going to depend entirely on whether the system has built-in support for that usage.
--
- Julian
- Julian