Hi, I'm generally ambivalent on which day it moves, though depending on how late in the day it comes out, it might not actually be Thursday - if the release comes out late at night, I'm more likely to finish up the migration over the weekend.
On Wed, 13 May 2020 at 13:43, Brian Paul <bri...@vmware.com> wrote: > On 05/13/2020 03:13 AM, Erik Faye-Lund wrote: > > 2. Some people have been asking me why the website is set up as a > > separate repo rather than a subdirectory inside the main mesa repo. > > > > The quick answer to that is that it seemed more logical that way to me. > > The website isn't really tied to the mesa release-schedule, apart from > > linking to new releases. It's really its own thing. We might for > > instance want to post updates when other projects in the mesa-group > > cuts a release. So this seems to give us some more freedom. > > > > If someone has good arguments against this, I'm open to changing it. > > But this seems like the best option to me. > > I'd really like to keep the Mesa content as part of the main Mesa repo. > I didn't realize you did that. The website is part of the project and > it's more convenient to have it all in one place. It's a fair point, but then there's the ageing issue with branches. If someone is working against the 19.3.x repo, they'll see a snapshot of the website at a pretty arbitrary point in time - whenever it was that it was forked. That doesn't sound ideal to me, nor does the alternate idea of picking back all the content to all our live branches (e.g. when we do a 20.0.x stable release, cherry-pick the news-page update to 19.3.x?). There's also a circular dependency issue related to publishing releases: it seems odd to commit and tag a release, then have the very next commit be the update to the page, which you can't do in one as you don't know the SHA before you commit. Code information and documentation _definitely_ belongs with the Mesa project though. Things like the Gallium3D documentation published out to ReadTheDocs should be maintained in with the code and generated with the code - and this should be extended through the whole Mesa source tree, so we have much better live docs of our codebase. I've been working with Erik to figure out how we can best get this published alongside the main website. We absolutely shouldn't be putting up any barriers to keeping the website updated and making sure we have good contributions to it, though. I think putting it in a separate repo actually makes it slightly easier if anything, provided that we have a good set of reviewers keeping eyes on it, and clear instructions on how to contribute to it. Cheers, Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
