Sigh. More process, more technology. At a time when our release managers are more burdened than ever.
Is there a significant problem where we publish a release and the site is screwed up? If so, let’s roll back the change to go to GitHub pages. When we generated the site locally using Jekyll there was opportunity to generate the site and review before publishing. If not, let’s stay as we are. If we notice problems after the release we can fix them within the hour. Julian > On Jul 2, 2019, at 10:50 AM, Michael Mior <mm...@apache.org> wrote: > > Comments inline. > > Le mar. 2 juil. 2019 à 16:17, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com <mailto:sitnikov.vladi...@gmail.com>> a écrit : >> >> Micael>How so? Just delete the branch or rebase to delete the commits. I >> fail >> to see the complexity here. >> >> The complexity is not technical. It is INFRA who prohibits rebases. >> That is why I suggest we don't put "build artifacts" into the main source >> repositories. >> In the worst case we just throw away "preview repo". >> >> Here is a recent relevant INFRA ticket: >> https://issues.apache.org/jira/browse/INFRA-18499?focusedCommentId=16865680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16865680 >> >> TL;DR there was <<history overwrite in Apache source repositories requires " >> vp-in...@apache.org or our infra admin escalation">> >> They denied to remove third-party jar files from the repository (e.g. >> lib/js_rhino1_6R5.jar), and I did not escalate that because, well, I don't >> want spend time there. >> > > We regularly force push to the Calcite repo, so this is not a > restriction we face. That said, I don't have any major problems with > creating a separate repo. > >> Michael>Why do we need both to be in the same repository if we're just >> using it for testing? >> >> I just assume they both could share some resources (e.g. css? images?) and >> have cross-links (e.g. Calcite site points to Avatica pages). >> So I thought it would be just simpler to put everything into a single repo >> so it looks closer to the production site. >> >> Do you suggest to have different "test" sites for Calcite and Avatica? >> > > The two repos are already separate so I don't think this is a big > departure. As above though, I'm not strictly opposed to a separate > repo. > >> Michael>With GitHub pages, published content is stored on a >> Michael>separate gh-pages branch. >> >> I'm used to `git clone https://github.com/organization/repo.git` >> <https://github.com/organization/repo.git%60> >> It clones all the branches and tags. >> Apparently gp-pages would be there as well. >> Do you think everybody is cloning git repositories in a different way? >> > > My mistake, this is a fair concern. > >> Vladimir
