21 Apr
2021
21 Apr
'21
5:13 p.m.
On 4/21/21 9:00 AM, Anthony D'Atri wrote:
I don't see it as a requirement for docs contributors, I think Zac and
developers familiar with backports can help with the backport process.
I'd rather make it easier to contribute to docs, not harder :)
Yes, it's a matter of applying effort where it's most useful.
Newer releases get more backports, and docs changes most easily apply
(in terms of content and cherry-picking difficulty) to more recent
releases. For pacific in particular, there's been significant
restructuring and retheming of the docs that makes backports
prior to that require more manual effort.
Josh
> Hey folks, now that Pacific is out I wanted
to bring up docs backports.
> Today, docs.ceph.com shows master by default, with an appropriate
> warning at the top that it represents a development version.
>
> Since the primary audience of the docs is users, not developers, I
> suggest that we switch the default branch to the latest stable, i.e.
> pacific
Agree.
> and apply the normal backport process to
docs that are
> relevant to the latest stable release as well.
As with any backport, we’ll of course want to be careful that docs changes to master are
appropriate for the stable release. Do you and/or Zac envision backporting as a
fundamental part of docs contributions? If so that will complicate the docs workflow a
bit and will itself need some specific documentation. Is there a
reason to limit docs only to one latest version?
Perhaps one has to draw the line somewhere? The farther back one goes, the more work it
takes to ensure that a given change is applicable to the release in question. Over time
the overhead and complexity of contributing has disuaded some docs contributors, so I’m
wary of adding friction.