Alright, created https://github.com/apache/beam-site/pull/520Reduces staging upload from 500M down to 270M, and halves the number of files from ~22k to 11k.On Thu, Aug 2, 2018 at 6:58 PM Pablo Estrada <pabloem@xxxxxxxxxx> wrote:I believe tags will be necessarily because for anyone looking for old docs that have been removed, they will need to browse back in history, not just browse the tree of directories.-P.--On Thu, Aug 2, 2018, 6:46 PM Mikhail Gryzykhin <migryz@xxxxxxxxxx> wrote:Last time I talked with Scott I brought this idea in. I believe the plan was either to publish compiled site to website directly, or keep it in separate storage from apache/beam repo.One of the main reasons not to check in compiled version of website is that every developer will have to pull all the versions of website every time they clone repo, which is not that good of an idea to do.Regards,On Thu, Aug 2, 2018 at 6:42 PM Udi Meiri <ehudm@xxxxxxxxxx> wrote:Pablo, the docs are generated into versioned paths, e.g., https://beam.apache.org/documentation/sdks/javadoc/2.5.0/ so tags are not necessary?Also, once apache/beam-site is merged with apache/beam the release branch should have the relevant docs (although perhaps it's better to put them in a different repo or storage system).Thomas, I would very much like to not have javadoc/pydoc generation be part of the website review process, as it takes up a lot of time when changes are staged (10s of thousands of files), especially when a PR is updated and existing staged files need to be deleted.On Thu, Aug 2, 2018 at 1:15 PM Mikhail Gryzykhin <migryz@xxxxxxxxxx> wrote:+1 For removing old documentation.@Thomas: Migration work is in backlog and will be picked up in near time.On Thu, Aug 2, 2018 at 12:54 PM Thomas Weise <thw@xxxxxxxxxx> wrote:+1 for removing pre 2.0 documentation (as well as the entries from https://beam.apache.org/get-started/downloads/)Isn't it part of the beam-site changes that we will no longer check in generated documentation into the repository? Those can be generated and deployed independently (when a commit to a branch occurs), such as done in the Apex and Flink projects.I was told that Scott who was working in the beam-site changes is on leave now and the migration is still pending (see note at https://github.com/apache/beam/tree/master/website). Is anyone else going to pick it up?Thanks,ThomasOn Thu, Aug 2, 2018 at 12:33 PM Pablo Estrada <pabloem@xxxxxxxxxx> wrote:Is it worth adding a tag / branch to the repositories every time we make a release, so that people are able to dive in and find the docs?Best-P.--On Thu, Aug 2, 2018 at 12:09 PM Ahmet Altay <altay@xxxxxxxxxx> wrote:I would guess that users are still using some of these old releases. It is unclear from Beam website which releases are still supported or not. It probably makes sense to drop documentation for releases < 2.0. (I would suggest keeping docs for 2.0). For the future I can work on updating the Beam website to clarify the state of each release.On Thu, Aug 2, 2018 at 12:06 PM, Udi Meiri <ehudm@xxxxxxxxxx> wrote:The older docs are not directly linked to and are in Github commit history.If there are no objections I'm going to delete javadocs and pydocs for releases older than 1 year,meaning 2.0.0 and older (going by the dates here).On Thu, Aug 2, 2018 at 11:51 AM Daniel Oliveira <danoliveira@xxxxxxxxxx> wrote:The older docs should be recorded in the commit history of the website repository, right? If they're not currently used in the website and they're in the commit history then I don't see a reason to save them.On Tue, Jul 31, 2018 at 1:51 PM Udi Meiri <ehudm@xxxxxxxxxx> wrote:Hi all,I'm writing a PR for apache/beam-site and beam_PreCommit_Website_Stage is timing out after 100 minutes, because it's trying to deletes 22k files and then copy 22k files (warning large file).It seems that we could save a lot of time by deleting the older javadoc and pydoc files for older versions. Is there a good reason to keep around this kind of documentation for older versions (say 1 year back)?
Description: S/MIME Cryptographic Signature