I think a separate repo for the website makes sense, to keep things a little separated. It depends on what route we choose regarding repos, but my preference would be to keep the main "content" repo free of any admin (for lack of a better word) stuff. Regarding a staging repo, for our website we currently forego this step completely, our build job takes the sources (we use Lektor) and compiles them straight to the directory the page is served from. While saving an extra repo this also means that we lack proper versioning, as any changes to the build job might of course also affect rebuilds of older versions of the page.
I don't have any real preference here tbh, I think we should mostly be looking to reuse as much as possible. Best regards, Sönke [1] https://www.getlektor.com Am Sa., 23. Feb. 2019, 21:01 hat Furkan KAMACI <furkankam...@gmail.com> geschrieben: > Hi, > > The website can be a separate repo ( > https://github.com/apache/incubator-dubbo-website), a different branch or > resides in the original repo ( > https://github.com/apache/incubator-druid/tree/master/docs). > > I think that it depends on which repositories we will have on Github. As > far as I see, a separate repo for such purpose could be better. Generating > a website from AsciiDoc > could be nice i.e. https://plc4x.apache.org or > https://cloudstack.apache.org > > On the other hand, generating a website from mkdocs via gh-pages ( > https://www.mkdocs.org/user-guide/deploying-your-docs/#github-pages) can > be > another option if possible. > > Kind Regards, > Furkan KAMACI > > > On Sat, Feb 23, 2019 at 7:17 PM Kenneth Knowles <k...@apache.org> wrote: > > > You can do it all in our repo: keep source for the site on `master` > branch > > and the rendered site on `asf-site`, much like GitHub does with > `gh-pages`. > > Beam does this. Slightly less to administer. But on the other hand, if > you > > *want* to set up permissions differently (like "only a bot can push"), or > > just want to stay flexible, then having a separate technical repo is > likely > > better. > > > > Kenn > > > > On Sat, Feb 23, 2019 at 2:17 AM Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > One thing with "one repo" and the reason we stage the website in a > > > separate one. > > > The commit history is polluted with all the website-staging > auto-emails. > > > > > > So I would suggest a "technical repo" where the site is staged for > pickup > > > by git-pub-sub. > > > > > > Chris > > > > > > Am 23.02.19, 11:07 schrieb "Lars Francke" <lars.fran...@gmail.com>: > > > > > > Fabulous! I think that looks good, I like Asciidoc, I understand > > Maven > > > so > > > to me that sounds good. Thank you. Let's see what others have to > say. > > > > > > All in one repo as Kenneth mentioned also sounds good to me. > > > > > > That reminds me: A logo would be good. The ASF now has a Central > > > Service > > > that we could ask for a Logo design. > > > > > > On Sat, Feb 23, 2019 at 10:35 AM Christofer Dutz < > > > christofer.d...@c-ware.de> > > > wrote: > > > > > > > Hi, > > > > > > > > well I could help with this. > > > > I guess the PLC4X podling is the cleanest of my examples for a > > setup > > > in > > > > which the website is generated from asciidoc as part of the maven > > > build > > > > And it is also automatically staged and published by git-pub-sub. > > > > IANAWD (I am not a web designer), and the content definitely > needs > > an > > > > update, but I'm quite happy with the results. > > > > > > > > https://plc4x.apache.org > > > > > > > > Chris > > > > > > > > Am 23.02.19, 01:06 schrieb "Kenneth Knowles" <k...@apache.org>: > > > > > > > > It can all be in one repo. Beam recently moved the site from > > the > > > > apache/beam-site repo to a directory in the main apache/beam > > > repo. It > > > > is > > > > nice to not have multiple places you have to go looking for > > > bits. And > > > > it is > > > > published on every commit using gitpubsub. I didn't set that > > up, > > > but I > > > > can > > > > ask around. We've had a pretty good time with Jekyll though I > > > think > > > > mostly > > > > we don't change it since it is working. I think various > flavors > > > of > > > > markdown > > > > have the most widespread support. > > > > > > > > Kenn > > > > > > > > On Fri, Feb 22, 2019 at 2:49 PM Lars Francke < > > > lars.fran...@gmail.com> > > > > wrote: > > > > > > > > > We need a website :) > > > > > > > > > > I have almost no skills in any kind of frontend work. > > CSS/HTML > > > etc. > > > > That > > > > > means I also don't have any strong opinions on this but I > > know > > > that > > > > some of > > > > > you (Christofer etc.) have already dealt with this in other > > > projects. > > > > > > > > > > I'm happy to help with content when the basics are set-up. > > > > > > > > > > The only opinion I do have is that it'd be good to have the > > > content > > > > in a > > > > > format like Asciidoc - ideally in the same format as > some/all > > > of our > > > > actual > > > > > content. > > > > > > > > > > It'd be fabulous if anyone is willing to take this up? > > > > > > > > > > I know that Infra has a "gitpubsub" thing which allows us > to > > > > automatically > > > > > build and deploy a site from git somehow. I've never used > it > > > and > > > > there are > > > > > lots of things I don't know. One of them being whether it > can > > > all be > > > > one > > > > > repository or whether we need a training-site repo. > > > > > > > > > > <https://www.apache.org/dev/project-site.html> > > > > > <https://www.apache.org/dev/gitpubsub.html> > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
