Daniel Sahlberg wrote on Sat, Jul 03, 2021 at 00:05:49 +0200: > Den sön 27 juni 2021 kl 23:36 skrev Daniel Shahaf: > > Daniel Sahlberg wrote on Sun, Jun 27, 2021 at 23:14:20 +0200: > > > Den sön 27 juni 2021 kl 20:34 skrev Daniel Shahaf: > > > Daniel Sahlberg wrote on Sat, 26 Jun 2021 21:12 +00:00: > There are additiona links for the years 2010, 2011, 2012, 2014, 2015 and > 2016 (in http://subversion.apache.org/docs/community-guide/general.html) > which I cannot find at all in the current elegosoft.com site. > > However "... meets in Berlin for a Hackathon once a year: 2016, 2015, ..." > doesn't seem very current. For this reason I'd suggest to remove the > complete paragraph from HACKING. Other option to rephrase "in the past ... > met in Berlin" and link to archive.org. >
I prefer not to remove the paragraph; it's a useful historical perspective. > > - Modify the link to point to elego's old site via archive.org. Pro: "As > > it > > > was supposed to be" Con: That page ( > > > > > https://web.archive.org/web/20171206002300/https://www.elegosoft.com/en_US/page/nachlese-subversion-hackathon-berlin-2013 > > ) > > > contains links to the interviews, but those links are 404. > > > - Keep the link, but mark it as obsolete. Pro: No re-writing of history. > > > Con: We loose some part of history. > > > - Copy the contents from archive.org and host it including the > > interviews > > > on the site or in WIKI. Pro: Preserve history. Con: Copyright issue needs > > > to be resolved with elego (and whoever took the photos). > > > > Fifth option: > > > > - Link to elego's page in archive.org, and mirror the interviews (with > > permission, if one is needed) > > > > I thought about this but I couldn't invent a way to inject the interviews > within archive.org and thus it didn't provide a good user expericen, which > is why I didn't list this as an option. > It's not the best UX, agreed, but it preserves all available content, and in English. Let's see what others think. > > > > > * There are a lot of links in /docs/ concerning older versions. > > Should > > > > > we keep them frozen as a historic document or try to update them? For > > > > > future versions, I will try to fix the obvious in the code (but > > that's > > > > > another project). > > > > > > > > Not sure what you have in mind here. Example? > > > > > > > > > > Links to java.sun.com in the javahl docs. This is probably from > > docstrings > > > in the source. > > > Links to www.doxygen.org in the api docs. These are "generated by". > > > > > > I'm leaning towards leaving old docs as-is (especially the "generated > > by"), > > > but change the docstrings in the source for a future release. > > > > > > > Sure. And FWIW, there's nothing stopping us from updating the links in > > the HEAD revision of old minor branches, including unsupported ones. > > That doesn't even require STATUS voting [1]. > > > > [1] > > https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization-backportable-changes > > > Alright. And it might be possible to only update this within the website > and not changing the old tags/regenerating the docs from source so no > voting required at all. However since it is quite a bit of work I'll only > do it if someone say "we MUST". > Sure. And to be clear, we shouldn't edit old tags for this. If we need to change a tag, we can create a branch off it, or make the change in the 1.A.x branch [assuming it has no other relevant changes]. > I'll try to find some time to update the docstrings in /trunk within the > next few weeks. Thanks, Daniel. Daniel
