git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: GitList <git@vger.kernel.org>
Cc: Self <philipoakley@iee.email>, Junio C Hamano <gitster@pobox.com>,
	Taylor Blau <me@ttaylorr.com>
Subject: [RFC/PoC 1/5] doc: provide DocBundles design document
Date: Wed,  2 Nov 2022 22:48:39 +0000	[thread overview]
Message-ID: <20221102224843.2104-2-philipoakley@iee.email> (raw)
In-Reply-To: <20221102224843.2104-1-philipoakley@iee.email>

DocBundles are exemplar repositories, provided as bundles, which
contain either 'interesting' test setups for exploration, or
the described examples from within the man pages.

Signed-off-by: Philip Oakley <philipoakley@iee.email>
---
 Documentation/technical/docbundle.txt | 97 +++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)
 create mode 100644 Documentation/technical/docbundle.txt

diff --git a/Documentation/technical/docbundle.txt b/Documentation/technical/docbundle.txt
new file mode 100644
index 0000000000..8c17a7847f
--- /dev/null
+++ b/Documentation/technical/docbundle.txt
@@ -0,0 +1,97 @@
+docbundle Design Document
+=========================
+
+The Git man pages contain many example setups to demonstrate aspects
+of the related Git commands, such as history simplification in the `log`
+and `show commands. However, while illustrative, these are not
+accessible, as example repositories, to regular, potentially confused,
+users who may need to understand the set up of the examples.
+
+The docbundle concept is that for each of these examples there is a
+matching `bundle` file, provided with the Documentation, which can be
+simply cloned to provide an example repository containing the example.
+
+There are also many example repositories in the Git `/t` test system
+that could be exposed to users which already demonstrate some important
+testable aspect of Git within a carefully constructed repository.
+
+
+This proposal is to provide DocBundles to users via the Git project.
+
+
+Firstly, it should be reasonably self-evident that the man page examples
+should, in themselves, be tested for accuracy, especially if provided
+to users.
+
+Secondly, the existing test system is the proper place to setup and
+test any such docbundle repositories.
+
+Third, that the bundle is an obvious pre-existing mechanism for
+transporting repositories (see also the Bundle-URI proposals).
+
+Fourthly, the preparation and distribution of the docbundle should
+require minimal maintainer effort, preferably being integrated into
+the existing automation for Documentation preparation and distribution.
+
+Fifthly, the docbudles themselves should not to be part of the git.git
+repo. They are prepared via the test suite and should be stored (locally)
+in a designated Git_DocBundle_Dir, and be .gitignored. The DocBundles
+are transferred to the maintainer's Doc repo via the automation.
+
+Sixthly, the docbundles to be named based on their `tnnnn` test number
+and a (short) descriptive name.
+
+Seven, (dev) start with an existing test, rather than add a test (most
+doc/man examples aren't tested!). Add tests for missing examples later.
+
+Eight, (option) add a `git docbundle` command to assist in locating and
+listing the docbundle examples. It also provides place to explain their
+purpose as "Tutorial Examples" (Note, many existing examples are to
+illustrate complex/difficult scenarios where the wording was insufficient;
+the docbudles are minimal examples).
+
+
+Status
+======
+
+This is an RFC/PoC (Request for Comment / Proof of Concept).
+
+The attached commits establish:
+
+Set out this design in the Documentation/technical directory.
+
+A default location for the docbundles and an env variable to allow
+flexibility by extending test-lib.
+
+The docbundles are ignored, as is the default directory.
+
+Two docbundles are generated from a 'random' test that I happened to
+have open in my editor (t6102 rev-list-simplify).
+
+The docbundle creation is protected by `test_expect_success` wrappers.
+
+
+
+ToDo
+====
+
+DocBundles - Is this the best name, or just a convenient way of
+indicating the delivery mechanism?
+
+Add Prerequisite to control if docbundles are generated (don't waste
+maintainers PC time when not needed).
+
+CI integration (i.e. whether to test the bundling aspect - should be
+reliable).
+
+How to update the man pages, perhaps by inclusion of the test comment
+(exported?), and distinguish between man page descriptions (being
+packaged by the test suite) and tests which offer users insight into
+Git operations, usually with 'interesting' commit-graph set-ups.
+
+Claim t999x as the man doc bundle test sequence ('999' is the UK
+emergency ("Help!") number; 911, 101 and 102 are taken test areas.
+
+Other stuff implicit in the eight point list
+
+
-- 
2.38.1.281.g83ef3ded8d


  reply	other threads:[~2022-11-02 22:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02 22:48 [RFC/PoC 0/5] Provide example docbundles Philip Oakley
2022-11-02 22:48 ` Philip Oakley [this message]
2022-11-03  9:19   ` [RFC/PoC 1/5] doc: provide DocBundles design document Ævar Arnfjörð Bjarmason
2022-11-03 19:50     ` Philip Oakley
2022-11-03 20:36       ` Ævar Arnfjörð Bjarmason
2022-11-02 22:48 ` [RFC/PoC 2/5] Documentation Bundles: ignore artifact files from creating doc bundles Philip Oakley
2022-11-03  9:12   ` Ævar Arnfjörð Bjarmason
2022-11-03 19:50     ` Philip Oakley
2022-11-02 22:48 ` [RFC/PoC 3/5] test-lib: add GIT_BUNDLE_DIR setup Philip Oakley
2022-11-03  9:14   ` Ævar Arnfjörð Bjarmason
2022-11-03 19:50     ` Philip Oakley
2022-11-02 22:48 ` [RFC/PoC 4/5] Doc Bundles: add t6102 rev-list simple and pulls examples Philip Oakley
2022-11-02 22:48 ` [RFC/PoC 5/5] docbundle: provide the git-log History Simplification example Philip Oakley
2022-11-03  9:17   ` Ævar Arnfjörð Bjarmason
2022-11-03 19:50     ` Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221102224843.2104-2-philipoakley@iee.email \
    --to=philipoakley@iee.email \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).