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 > > >>> > > >> > > >
