On Thu, 29 Apr 2021 at 15:37, Alex Herbert <alex.d.herb...@gmail.com> wrote: > > On Thu, 29 Apr 2021 at 12:49, sebb <seb...@gmail.com> wrote: > > > On Thu, 29 Apr 2021 at 12:00, Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > > Le jeu. 29 avr. 2021 à 01:45, sebb <seb...@gmail.com> a écrit : > > > > > > > > On Thu, 29 Apr 2021 at 00:10, Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > > > > > > It occurs to me that we *should* create a specific "git" repository > > > > > for holding web site contents; having the "asf-site" and > > "asf-staging" > > > > > branches in the component's repository is looking for trouble: It > > will > > > > > be too easy to commit the (generated) web files into "master" > > > > > instead of the appropriate branch. [If allowed (even recommended > > > > > as per the doc) by INFRA, we should not frown upon the increased > > > > > separation of concern (source code vs web site management).] > > > > > > > > > > "Logging" has one repository for the top-level site and a separate > > > > > repository for every component. > > > > > IMO, we should do the same (and copy their ".asf.yaml" layout). > > > > > > > > You are proposing about 50 new Git repos. > > > > > > Only because it seems that the functionality was intended that way. > > > > Not as far as I know; many repos have asf-site and asf-staging > > branches alongside the code. > > > > > Also: Having independent repositories seems the safest path for > > > experimenting mix and match; if the latter works, not all components > > > will use the new system, or migration can be done gradually. > > > > It does not matter whether the branches are in the same or a different > > repo. > > > > IIUC it does for anyone using 'git clone ...' to get the source code. They > will be subjected to a download of all the site history. This may become > significant over time relative to the size of the source.
That's a good point. Looks like we will have to put up with lots of Git repos if we start to use Git for the site builds. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org