>1) I guess we'd better have a single repository for both Avatica and Calcite Why do we need both to be in the same repository if we're just using it for testing?
>2) Pushing site/reports to Git repository (e.g. apache/calcite.git) would >count towards repository size , thus it would impact every users of >Avatica/Calcite sources Only if people are fetching all branches, which I don't think is the common case. With GitHub pages, published content is stored on a separate gh-pages branch. >removing old commits from regular source repositories is very complicated. How so? Just delete the branch or rebase to delete the commits. I fail to see the complexity here. >I guess GitHub pages is the most simple and well-understood approach. I was agreeing with your GitHub pages suggestion, just using the existing repo. -- Michael Mior [email protected] Le lun. 1 juil. 2019 à 14:35, Vladimir Sitnikov <[email protected]> a écrit : > > Michael>Why not just use GitHub pages > Michael>on the existing repositories? > > 1) I guess we'd better have a single repository for both Avatica and Calcite > 2) Pushing site/reports to Git repository (e.g. apache/calcite.git) would > count towards repository size, thus it would impact every users of > Avatica/Calcite sources > > Typically we don't want to store build artifacts side by side with the > sources. > > If we use a dedicated repository, then we can throw it away if it becomes > too big for some reason. > On the other hand removing old commits from regular source repositories is > very complicated. > > I guess GitHub pages is the most simple and well-understood approach. It > works, and it has little damage scope. > > Vladimir
