[Mesa-dev] New Mesa3D.org website proposal

[Daniel Stone]

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 <brianp at 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