To close the loop on this, the website automation is now live! Any changes to the mesos repo will trigger the Mesos-Websitebot CI job that builds and publishes an updated website that gets reflected on http://mesos.apache.org
Enjoy! On Tue, Jun 13, 2017 at 12:24 PM, Vinod Kone <vinodk...@apache.org> wrote: > This process has started. Tracking ticket: https://issues.apache. > org/jira/browse/INFRA-14289 > > Please avoid doing any commits to the *svn repo* until further notice. > > > > On Fri, Jun 2, 2017 at 4:21 AM, Timothy Anderegg < > timothy.ander...@gmail.com> wrote: > >> Ah, that makes more sense, thanks! >> >> On Fri, Jun 2, 2017 at 12:57 AM Vinod Kone <vinodk...@gmail.com> wrote: >> >> > Tim, with the 2 repo option, the idea is that the source of the website >> > will still reside in the main repo even if we keep the publish contents >> in >> > a different repo. >> > >> > @vinodkone >> > >> > > On Jun 1, 2017, at 8:42 PM, Timothy Anderegg < >> timothy.ander...@gmail.com> >> > wrote: >> > > >> > > Just to chime in, I'm almost done with the changes to the website code >> > that >> > > allows the user to select the version of documentation they wish to >> see >> > > (haosdent is reviewing the final revisions), and it does depend on >> using >> > > git to checkout the previous versions of the website via tags, so if >> we >> > did >> > > isolate the website code to a specific branch or repo, we would also >> need >> > > to ensure that the tags of commits to the website code stay in sync >> with >> > > tags of commits to the actual code. This would not be too >> challenging, >> > but >> > > something to keep in mind. >> > > >> > > Keeping the website code in a separate repository might be easier to >> > manage >> > > from this perspective, since tags are effectively global to a given >> repo, >> > > so if we kept the website code in a special branch within the main >> repo, >> > > we'd need something like a tag called "1.3.0" for the main code, and >> > > "website-1.3.0" for the website code, which could be confusing. >> > > >> > >> On Thu, Jun 1, 2017 at 8:53 PM Vinod Kone <vinodk...@gmail.com> >> wrote: >> > >> >> > >> Thanks for the analysis Benjamin. Really appreciate it. >> > >> >> > >> You bring up good points esp about size bump for supporting multiple >> > >> versions. >> > >> >> > >> Btw, do the numbers change if publish content is only in a branch ? >> > Guess >> > >> not? >> > >> >> > >> Maybe we can start with a separate git repo and see if it's painful >> > enough >> > >> to merge it into our source repo. >> > >> >> > >> @vinodkone >> > >> >> > >>> On Jun 1, 2017, at 4:06 PM, Benjamin Bannier < >> > >> benjamin.bann...@mesosphere.io> wrote: >> > >>> >> > >>> Hi Vinod, >> > >>> >> > >>>> *Implementation details: * >> > >>>> >> > >>>> We have an option to move to >> > >>>> 1) a standalone git repo (say "mesos-site") which will be mirrored >> on >> > >>>> github. >> > >>>> 2) just use our "mesos" git repo and publish a "asf-site" branch >> with >> > >>>> website contents (say at 'site/publish' directory) >> > >>>> >> > >>>> I'm leaning towards 2) because that allows us to deal with single >> repo >> > >>>> instead of two. >> > >>> >> > >>> I have never updated the website so I cannot comment on the pain >> > >> involved. >> > >>> >> > >>> As a user of the Mesos source git repository I would however like to >> > >> bring up that _all_ of the website’s assets are generated from files >> > >> present in the source repository (at some point in time). The largest >> > >> fraction of the `publish` directory is Doxygen documentation >> (currently >> > >>> 90% at ~100 MB). We should weigh the effect this would have for >> > developers >> > >> should we add this content to the Mesos source repository. >> > >>> >> > >>> To get a ballpark idea I imported the website’s history into a git >> > >> repository. After the initial import its `.git` directory contained >> > ~100 MB >> > >> which went down to ~30MB after aggressive repository repacking. A >> fresh >> > >> clone of the Mesos source repository amounts to ~280 MB, so it seems >> we >> > >> would add at least 10% to the repositories size with little benefit >> to >> > >> developers. Depending on the implementation, this number would likely >> > >> increase would we e.g., provide version-dependent website content, or >> > >> introduce website asset formats not compressing as nicely with git >> > (e.g., >> > >> generated graphics). >> > >>> >> > >>> I have the feeling keeping this content in a separate repository >> might >> > >> strike a better balance for developers. >> > >>> >> > >>> >> > >>> Benjamin >> > >>> >> > >> >> > >> > >
