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. > > > Until we make the git switch for the live top-level site, we would indeed > > > (as you proposed) not have a "publish" section in any of the ".asf.yaml" > > > files (in any of the repositories); we'd only use the "staging" section > > > that will make the site accessible at > > > https://commons.staged.apache.org > > > > The top-level site does NOT have to be switched to Git for this to work. > > As I already wrote we can mix SVN and Git. > > I propose this in order to be able to test the *full* solution without > messing with the current setup, based on what you wrote previously: > That > https://commons.staged.apache.org > would go away. [It's not: It will be used as the staging site through the > ".asf.yaml" mechanism (cf. doc).] Sorry, I was wrong about that. > > But of course the way the website is built needs to be changed to > > select the individual parts as already described. > > This means a change to the svnpubsub configuration. > > > > > Any objection to creating the following repositories: > > > commons-site.git > > > > -1: it's not needed; we can still use the SVN repo. > > > > > commons-math-site.git > > > ? > > > > Fine, but please try (and document) the full process of how to stage > > the site and how to push the staged site to the asf-site branch. > > Practical question: Do we care about getting lots commit messages > sent to the commits@ ML during the test phase? > Or should I direct the traffic to some other list (which one?) in the > meantime > > > There's no point converting to Git if that process is more involved > > than the existing process. > > I'm not sure that we mean the same with "the existing process". > Earlier in the thread, I've described what I do: > > $ mvn site site:stage > $ cd site-content > $ rm -rf * > $ cd ../target/staging/ > $ cp -r * ../../site-content > $ cd ../../site-content > $ svn status > [Use some commands to "svn add" all the new files and "svn del" > to remove all the file that do not exist anymore.] > $ svn commit AFAIK that can all be done with 'mvn site:publish' though I could be wrong. > What I'd like to know is whether the "process" should be different > with the current setup. > > IIUC, the ".asf.yaml" approach is to create a subdirectory for each > new version of the web site (in sync with versions of the code). No, subdirectories for each version is independent of the .asf.yaml approach. > So that the last two steps of the "process" above would just be (within > a newly created subdirectory). > $ git add -A > $ git commit > > Gilles > > > > > > [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
