On Sun, Aug 5, 2018 at 5:28 AM Thomas Weise <t...@apache.org> wrote: > > Yes, I think the separation of generated code will need to occur prior to > completing the merge and switching the web site to the main repo. > > There should be no reason to check generated documentation into either of the > repos/branches.
Huge +1 to this. Thomas, would have time to set something like this up for Beam? If not, could anyone else pick this up? > Please see as an example how this was solved in Flink, using the ASF buildbot > infrastructure. > > Documentation per version/release, for example: > > https://ci.apache.org/projects/flink/flink-docs-release-1.5/ > > The buildbot configuration is here (requires committer access): > > https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/flink.conf > > Thanks, > Thomas > > On Thu, Aug 2, 2018 at 6:46 PM Mikhail Gryzykhin <mig...@google.com> 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, >> --Mikhail >> >> Have feedback? >> >> >> On Thu, Aug 2, 2018 at 6:42 PM Udi Meiri <eh...@google.com> 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 <mig...@google.com> wrote: >>>> >>>> +1 For removing old documentation. >>>> >>>> @Thomas: Migration work is in backlog and will be picked up in near time. >>>> >>>> --Mikhail >>>> >>>> Have feedback? >>>> >>>> >>>> On Thu, Aug 2, 2018 at 12:54 PM Thomas Weise <t...@apache.org> 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, >>>>> Thomas >>>>> >>>>> >>>>> On Thu, Aug 2, 2018 at 12:33 PM Pablo Estrada <pabl...@google.com> 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 <al...@google.com> 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 <eh...@google.com> 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 >>>>>>>> <danolive...@google.com> 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 <eh...@google.com> 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)? >>>>>>> >>>>>>> >>>>>> -- >>>>>> Got feedback? go/pabloem-feedback
