Uploaded image for project: 'Couchbase Documentation'
  1. Couchbase Documentation
  2. DOC-6861

Documentation should not be kept in code repositories

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Won't Fix
    • Major
    • None
    • None
    • doc-system
    • 1

    Description

      The current git branching / manifest build process has been devised over years to account for the many requirements of development, in particular Server's requirements for parallel development across multiple versions and for a relatively complex series of point and patch releases.

      This process does not meet Doc requirements, as we have found in a number of ways over the years. For instance:

      1. Docs frequently need to be updated near to release time. This falls afoul of our "restricted branch" mechanism, which requires all commits to code repositories be approved for inclusion in a given release. It also generates additional unnecessary builds right at the end of the release cycle, which causes confusion and distress for QE.
      2. Docs often need to continue being changed for a given release after that release has already shipped. This has all the same problems as #1, only more so. It also introduces a bigger problem, in that the git branches for the code often no longer correspond to the version that the Docs need to be changed for. For instance, right now the 'mad-hatter' git branch of the backup project is for 6.6.0, but Docs needs to make changes for 6.5.1. There is no place in git to put 6.5.1-specific changes, and even if we created a "6.5.1" branch, that introduces significant additional maintenance requirements (merging those changes up to mad-hatter, or copying them over to 6.5.2 if there ever is one, all the while worrying about restricted-branch issues). See MB-39552.

      We've implemented a work-around for #1 with the "doc-change-only" label in Jira, but that is a bandaid, not a solution. It is also a source of increased risk for our products, however minor.

      I cannot see a solution or work-around for #2, though. The simple fact is that Docs and Code do not have the same lifecycle requirements, and hence for the most part they cannot be housed and branched the same way. We can continue to make special-case work-arounds, ad-hoc git branches, and so on. But it would be much cleaner and clearer if the Docs simply lived in a different repository from the code, and were branched in a way that made sense for Docs.

      Note I am talking specifically about website docs in this ticket, or any other docs which are not shipped with the product. Any docs that are shipped, such as manpages, by necessity must have the same lifecycle as the code itself, and those docs must be available to the production builds so they can be packaged with the product. Hence it makes sense for such docs to live in the same repository.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              amarantha.kulkarni Amarantha Kulkarni (Inactive)
              ceej Chris Hillery
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty