From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 52D4643881; Wed, 10 Jan 2024 11:42:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC9B340298; Wed, 10 Jan 2024 11:42:07 +0100 (CET) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id C09C640269 for ; Wed, 10 Jan 2024 11:42:06 +0100 (CET) Received: by inbox.dpdk.org (Postfix, from userid 33) id 99DBE43883; Wed, 10 Jan 2024 11:42:06 +0100 (CET) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [Bug 1356] Documentation structure, additions and cleanup Date: Wed, 10 Jan 2024 10:42:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: dts X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: juraj.linkes@pantheon.tech X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17048833261.f2202B.2480567 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --17048833261.f2202B.2480567 Date: Wed, 10 Jan 2024 11:42:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1356 Bug ID: 1356 Summary: Documentation structure, additions and cleanup Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: dts Assignee: dev@dpdk.org Reporter: juraj.linkes@pantheon.tech CC: juraj.linkes@pantheon.tech, probb@iol.unh.edu Target Milestone: --- There are different aspects we could and should document: * User documentation * Developer documentation * Api documentation * Test suite documentation Additionally, this page outlines what good documentation should contain: https://documentation.divio.com/. User Documentation The user docs are what we have in doc/guides/tools. These should contain the tutorials and how-to guides about testbed setup and how to run/configure DT= S. There may be parts which would be better placed in developer documentation (such as the docs guidance). Developer Documentation The developer docs should be understanding-oriented. These should contain t= he architecture, what are good (and bad) coding practices with explanations, w= hat to put into a commit message and so on. There could also be some tutorials and how-to guides. There should probably two parts, one for framework developers and one for t= est suite developers. The test suite developers docs may actually be in the user docs. We don't a clear where we'd put the developer docs. API Documentation This is the reference mainly for framework developers, but test case develo= pers would find it useful as well. The place to put these has been discussed and would be placed alongside DPDK API docs. Test Suite Documentation This is different from the test suite developer docs mentioned above. The t= est suite developer docs is about how to implement a test suite and related resources. This documentation is about documenting the test suite itself - = what it's testing, what configuration is needed and so one. The place to put this documentation is currently the test suite Python file= . If we adopt a YAML-based test case definition file, we may need to move some (= or all) of it to the YAML file. --=20 You are receiving this mail because: You are the assignee for the bug.= --17048833261.f2202B.2480567 Date: Wed, 10 Jan 2024 11:42:06 +0100 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
Bug ID 1356
Summary Documentation structure, additions and cleanup
Product DPDK
Version unspecified
Hardware All
OS All
Status UNCONFIRMED
Severity normal
Priority Normal
Component dts
Assignee dev@dpdk.org
Reporter juraj.linkes@pantheon.tech
CC juraj.linkes@pantheon.tech, probb@iol.unh.edu
Target Milestone --- 

There are different aspects we cou=
ld and should document:
* User documentation
* Developer documentation
* Api documentation
* Test suite documentation

Additionally, this page outlines what good documentation should contain:
https://documentation.divio.co=
m/.

User Documentation
The user docs are what we have in doc/guides/tools. These should contain the
tutorials and how-to guides about testbed setup and how to run/configure DT=
S.
There may be parts which would be better placed in developer documentation
(such as the docs guidance).

Developer Documentation
The developer docs should be understanding-oriented. These should contain t=
he
architecture, what are good (and bad) coding practices with explanations, w=
hat
to put into a commit message and so on.
There could also be some tutorials and how-to guides.
There should probably two parts, one for framework developers and one for t=
est
suite developers. The test suite developers docs may actually be in the user
docs.
We don't a clear where we'd put the developer docs.

API Documentation
This is the reference mainly for framework developers, but test case develo=
pers
would find it useful as well. The place to put these has been discussed and
would be placed alongside DPDK API docs.

Test Suite Documentation
This is different from the test suite developer docs mentioned above. The t=
est
suite developer docs is about how to implement a test suite and related
resources. This documentation is about documenting the test suite itself - =
what
it's testing, what configuration is needed and so one.
The place to put this documentation is currently the test suite Python file=
. If
we adopt a YAML-based test case definition file, we may need to move some (=
or
all) of it to the YAML file.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17048833261.f2202B.2480567--