Update Mixer documentation #80

kevincwells · 2018-01-26T20:07:58Z

Updating the documentation for mixer to account for recent changes,
and to better clarify some concepts. This is to coincide with an
upcoming release of mixer, in which several important changes will
be introduced.

The mixer CLI has been rewritten, supporting POSIX-style flags
and a modern command layout. This is a breaking change, as commands
and flags have been renamed.
The initialization steps for mixer have been further automated,
so the documentation has been updated to account for the new,
simpler approach.
Documentation has been added for the recent command for
automating the addition of bundles to a mix.
The tool now handles caching upstream CLR bundle definitions
in a more automated way, and so the 'mixer get-bundles' command
(and its corresponding documentation section) has been removed.

Signed-off-by: Kevin C. Wells kevin.c.wells@intel.com

kevincwells · 2018-01-26T20:19:11Z

@tmarcu -- please read this over and verify its accuracy. The diff might not be incredibly useful (effectively the entire file has been changed at least slightly), so you might want to just read the final file.

This PR has a lot of little clean-up throughout, trying to consistently use the :file:`path/to/file.ext` and other inline formatting techniques. That said, I notice clearlinux.org doesn't actually take advantage of many of these, as the stylesheets render much of these modified texts the same.

This builds and appears to render correctly for me, but I am not pulling in all the final stylesheets used on clearlinux.org.

Updating the documentation for mixer to account for recent changes, and to better clarify some concepts. This is to coincide with an upcoming release of mixer, in which several important changes will be introduced. 1) The mixer CLI has been rewritten, supporting POSIX-style flags and a modern command layout. This is a breaking change, as commands and flags have been renamed. 2) The initialization steps for mixer have been further automated, so the documentation has been updated to account for the new, simpler approach. 3) Documentation has been added for the recent command for automating the addition of bundles to a mix. 4) The tool now handles caching upstream CLR bundle definitions in a more automated way, and so the 'mixer get-bundles' command (and its corresponding documentation section) has been removed. Signed-off-by: Kevin C. Wells <kevin.c.wells@intel.com>

rcaballeromx · 2018-01-26T20:21:50Z

@kevincwells Thank your for this update. I'll review and provide comments. Regarding the inline markup: Not all classes have been implemented on the website's CSS but they are imperative for our automated document based testing efforts. Thank you for using them.

Merge branch 'mixer-doc-update' of https://github.com/kevincwells/clear-linux-documentation into mixer-doc-update

Signed-off-by: Ecouzens <evan.couzens@intel.com>

tmarcu · 2018-02-07T21:04:42Z

source/clear-linux/guides/maintenance/mixer.rst

+
+   Behind the scenes, mixer uses a local cache of the upstream Clear Linux
+   bundle definitions. These are stored in the 
+   :file:`.mixer/upstream-bundles/clr-bundles-{VER}/bundles/` directory in your


@kevincwells I'm sure this doesn't need to be said, but this kind of content will have to be updated as the new bundle/folder PR changes go in soon :)

ECouzens

Reviewed and committed changes

matthewrsj · 2018-02-14T20:52:13Z

bump

tmarcu · 2018-02-14T20:57:24Z

@rcaballeromx @ECouzens What is going on with this PR...?

ECouzens · 2018-02-15T17:34:41Z

@tmarcu apologies . We're waiting for an additional SW release this week before we merge this PR. @bktan8 will verify when that's released and will comment here when we are go for merge

tmarcu · 2018-02-22T23:03:46Z

😀

kevincwells · 2018-02-22T23:16:33Z

@rcaballeromx @ECouzens -- There have been new additions to the mixer tool since this PR was added. I'd like to update the docs to reflect them, but I'm a bit stuck with this PR still outstanding.

Would you prefer I:

Update this branch (force push) with new content
Add a new commit to this branch with new content
Start a new branch (and submit a new PR) that is, temporarily, based on top of the commits in this branch, and then rebase on top of master once this is merged?

I don't want to mess up your validation/merge process, so I won't make any changes to this branch without your approval.

mrkz · 2018-02-27T15:06:55Z

@rcaballeromx ^

rcaballeromx · 2018-02-27T15:30:29Z

@kevincwells The correct answer is option 2. Just as you would in the code, please make any updates on this content on this branch but in different commits. Thanks!

tmarcu · 2018-02-27T18:08:26Z

The new Mixer is now released in upstream, so this documentation has to get in ASAP. @kevincwells is this already ready to push on your end?

kevincwells · 2018-02-27T19:28:55Z

@rcaballeromx -- I'm definitely willing to do that, but wouldn't that effectively invalidate the two approvals and other review that has gone through on this PR? The new commits would need to go through a new approval.

Is there actually still something preventing this commit from being merged?

kevincwells · 2018-02-27T19:29:21Z

@tmarcu -- It's about half done and is my top priority today.

rcaballeromx · 2018-02-27T20:17:16Z

@kevincwells You are absolutely correct, just as it would with code. I haven't merged this content because based on the comments, it is clear that it is not complete.
As soon as you complete the content, I will review. This is also my top priority for today.

bktan8 · 2018-02-27T20:39:21Z

source/clear-linux/guides/maintenance/mixer.rst

@@ -70,211 +92,267 @@ Mixing
      VERSIONURL=<URL where the version of the mix will be hosted>
      FORMAT=1



This builder.conf is missing the [Server] and [Mixer] sections:

[Mixer]
LOCAL_BUNDLE_DIR=/home/clr/mix/local-bundles

[Server]
debuginfo_banned=true
debuginfo_lib=/usr/lib/debug/
debuginfo_src=/usr/src/debug/

@bktan8 Thanks for taking a look at this. Yes, this is one of the changes coming in the update for 4.0

bktan8 · 2018-02-27T20:48:42Z

source/clear-linux/guides/maintenance/mixer.rst

+
+   This command copies the specified bundle defintion files from your
+   configured upstream version of Clear Linux (:file:`.clearversion`) into
+   your :file:`mix-bundles` directory.


I don't see the "mix-bundles" directory in my testing. I see a "mixbundles" file which contains a list of bundles.

Again, yes, while these docs have been valid for the last month, new changes have been made in that time that make much of this outdated. I'm updating the documentation as we speak.

tmarcu · 2018-02-27T20:55:09Z

@bktan8 @rcaballeromx please do not review this PR any more until the new commits are in.

This was complete with multiple approvals, but it got mangled with absolutely irrelevant commits and then left to get stale for a month.

bktan8 · 2018-02-27T20:56:58Z

got it!

rcaballeromx · 2018-02-27T20:58:49Z

@tmarcu Understood. I won't review until you or @kevincwells let me know.

kevincwells · 2018-02-28T18:59:55Z

@rcaballeromx @ECouzens @bktan8 -- I've pushed a new commit with the updates to cover what's new in Mixer 4.0.

@ECouzens -- I liked what you were trying to do with the jump-to-label tag for "Step 4", but I had to remove it, because it broke the auto-numbering for the list. It made that section start a new count, so that section was no longer being numbered "4.", but instead "1."

new changes

kevincwells · 2018-03-02T22:45:17Z

@rcaballeromx -- @bktan8 has pointed out a couple of places that need updated. I can submit a new push in the next half hour that fixes these things. I'll post here when I do, so please be sure to pull the latest version.

bktan8 · 2018-03-02T22:46:20Z

source/clear-linux/guides/maintenance/mixer.rst

+   RPM files and not corrupt.
+
+#. **Add/remove/edit/list the bundles in your mix**. The bundles in your mix are
+   specified in the Mix Bundle List. This list is stored as a flat file called


@kevincwells - is there a reason M, B, and L are capitalized in "Mix Bundle List"?

I don't want to get into a grammar argument about what constitutes a "proper noun", but the short version is that I was treating it as one, a) to improve clarity and help people understand that this is a specific, unique thing, and b) to be consistent with the way it is written throughout all of the new command help doc information.

I can do both a without the capitalization. Sadly, b means that the help doc must be revised at a later date. As any writer can attest, you cannot fight grammar. I'll make sure to mark it clearly to achieve the desired clarity and specificity.

Is there actually a reason to remove these capitalizations, here and throughout the commands and code comments? Just to be completely clear, the capitalization is not grammatically incorrect. It might be against our adopted style guide (do we actually have one?), but that's a different concept altogether.

@kevincwells Yes there is. The dictionary is clear: https://en.oxforddictionaries.com/spelling/using-capital-letters
We have had a style guide for months. You can find the capitalization rules here: https://clearlinux.org/documentation/clear-linux/reference/collaboration/documentation/grammar
I will follow both the Oxford grammar and our style guide in my final tweaks.

@rcaballeromx

Thanks for linking me to the style guide -- when I asked if we have one, that was indeed a serious question. I have bookmarked the page and will do my best to adhere to it.

In regards to the style guide and the OED link -- I see nothing at all at either link that disputes this capitalization. The OED link is specifically a list of situations in which "you should always use a capital letter" -- it makes no assertions about when you should not. To my surprise, it makes no mention of the word "proper noun", which is often one of the cases cited. The style guide, however, does state that. "Mix Bundle List" is, in fact, a proper noun.

OED's definition for proper noun is quite open, defining it through contrast to a common noun: "A noun denoting a class of objects or a concept as opposed to a particular individual."

Merriam-Webster, Dictionary.com, and Wikipedia make the distinction in both their definition of proper noun and common noun: a "proper noun" is a noun that refers to a unique entity, while a "common noun" refers to a non-unique instance from within a class of entities.

While there are many lists, there is only one Mix Bundle List.

This same definition says that we should, in fact, actually capitalize "Mixer" when we are referring to it as the entity: there are many mixers (things that mix other things), but there is one Mixer (the tool to build Clear Linux update content). And that would 100% be in keeping with the style guide. Where we should not capitalize "mixer" (and the style guide addresses this when referring to not changing the case of software components) is when it is a literal command, referring to the lowercase-m binary executable.

As such, it would be appropriate to write: "To begin using Mixer, run mixer init."

rcaballeromx · 2018-03-02T22:49:06Z

@kevincwells @bktan8 My day is almost over and I do need to change some markup and minor punctuation. Make your changes and I will pull them first thing Monday morning to make mine and have them ready by the time you get in the office.

This patch updates the documentation to comply with all of the new changes Mixer 4.0 introduces: - Many changes to the bundle lifecycle. It introduces the concept of "local" and "upstream" bundles, and several new commands to work with them. - The new, native implementations of swupd-server and the bundle-chroot-builder tool, both still in experimental mode behind optional flags. - New default values for mixer init Signed-off-by: Kevin C. Wells <kevin.c.wells@intel.com>

kevincwells · 2018-03-03T00:39:59Z

@rcaballeromx @bktan8 I've added the clarification to mixer bundle remove, and added the new section for the mixer versions update command. I've also run additional spellchecking and caught a few more.

Let me know if you run into any issues with your final tweaks tomorrow.

rcaballeromx · 2018-03-05T17:06:25Z

source/clear-linux/guides/maintenance/mixer.rst

+
+   If you are creating RPMs from scratch, you can use ``autospec``, ``mock``,
+   ``rpmbuild``, etc. to build them. If they are not built on Clear,
+   make sure your configuration and toolchain builds them correctly for Clear,


What does it mean to build the RPM correctly for Clear? The text never explains.

That is a good question. I didn't change the wording here (it appears as new lines, but it's just been reformatted) because I don't know enough about Clear's RPM requirements to articulate it.

Could @matthewrsj @phmccarty or someone elaborate on what could go here?

We can link to https://github.com/clearlinux/common for this section. I don't want to explain any of it in here though, because it will make it too long and off topic.

@tmarcu I agree, the link is sufficient.

rcaballeromx · 2018-03-05T19:02:02Z

@kevincwells I am frankly not that worried about the capitalization issues. I have been fixing them as I go while editing and you can take a look at the final draft. Content-wise however, the text has more serious issues like excessive use of passive voice and relative pronouns, incorrect cross-referencing, and inconsistent use of terminology. I am working on a draft fixing all these issues but it is taking a lot longer than expected due to the complexity of the content. I am working hard at it to have a draft uploaded by today EoD.

kevincwells · 2018-03-05T19:06:26Z

@rcaballeromx 😀 I wholeheartedly believe you and appreciate you fixing those things.

…ar-linux-documentation into kevincwells-mixer-doc-update

The rewrite includes: Explicit commands for important options. Use of lists to improve the clarity of the configuration variables content. Removal of command prompts to enable DBT. Consistent use of terminology. Use of concrete examples to improve the clarity of the commands. Improved content flow and navigation with linked workflow overviews. Added cross-references. Removed ambiguous relative pronouns and punctuation. Removed passive voice whenever possible. Changed verbs to present tense for consistency and style guide compliance. Optimized headings for search engines. Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>

…ar-linux-documentation into kevincwells-mixer-doc-update

rcaballeromx · 2018-03-06T19:22:27Z

@tpleavitt Thank you for the comments. @ECouzens is performing an additional copy edit to clean up all those typos and artifacts that get introduced by massive rewrites. @kevincwells @tmarcu Can you take a look and ensure the content is still technically accurate? I tried to keep the technical information intact while providing more explicit command examples. Lastly, keep in mind that all '#' command prompts were replaced with sudo to prepare the document for automated testing.

kevincwells · 2018-03-06T19:28:56Z

@rcaballeromx I'm reviewing now. Very happy with the structural changes -- great work. I'm doing the technical comments as part of a formal "Review", so those will come in a few minutes when I'm done. 😄

Signed-off-by: Ecouzens <evan.couzens@intel.com>

kevincwells

@rcaballeromx -- Great rewrite! I love the new sections (way better than the fragile numbered list) and all of the additional example commands you inserted. You did a great job.

I've found a number of technical issues, though almost all are really minor. Almost all of the sudo's need to be dropped -- I noted each one individually because not all need to be dropped, and I wanted it to be explicitly clear which to remove. (Apologies in advance that this makes it look like there are a ton of edits; at least 40 of them are these one-word changes.) The rest of the technical issues are mostly details that got lost in translation.

I've marked all things that I feel need to be changed as "requested edits", and marked a few optional things as "suggested edits".

Because this is, technically, my own Pull Request, Github will not allow me to mark my review as "Request changes". I am definitely capable of making the changes I noted myself, but given that this commit is yours, I'd prefer if you edited it.

For reference, I find that the practice of your team pushing commits to my own personal repo's pull request branch leads to a lot of confusion on my part. I understand with a rewrite as extensive as this one, it makes sense for your team to do it yourselves and push a commit. In general, however, my personal branch should really only be edited by me.

kevincwells · 2018-03-06T18:55:27Z

source/clear-linux/guides/maintenance/mixer.rst

+#. `Create an image`_
+
+Alternatively, the following workflow applies if the mix only uses |CL|
+bundles.


This is misleading. Technically, this workflow applies if the mix only uses Clear Linux content. The bundles themselves can be edited, or completely original, so long as they only include packages available in upstream CLR.

Suggested edit: just replace "bundles" with "content".

kevincwells · 2018-03-06T18:59:03Z

source/clear-linux/guides/maintenance/mixer.rst

-   specified in the builder.conf, in this case ``/home/clr/mix/mix-bundles``.
-   This is where the bundle definitions are stored for your mix, and it's where
-   the chroot-builder looks to know what bundles must be installed.
+   sudo mixer init


The sudo on these commands was stripped deliberately. Specifically, init should not be run with sudo, or the configuration content will be created and owned by root. It's not the end of the world if this happens (I don't think we need any kind of warning against doing so), we just shouldn't include the sudo in our instructions.

Requested edit: remove sudo

kevincwells · 2018-03-06T19:03:52Z

source/clear-linux/guides/maintenance/mixer.rst

+based on the latest released upstream |CL| version. If a :file:`builder.conf`
+file is not already present in your workspace, mixer creates a default configuration
+file along with several version and tracking files and two bundle directories:
+:file:`local-bundles` and :file:`upstream-bundles`.


This is misleading. This technically says that the version tracking and bundle directories are created if builder.conf is not already present. The creation of these files and directories is not tied to the existence of builder.conf.

I split it into two sentences to reflect that the creations are independent from each other.

kevincwells · 2018-03-06T19:06:22Z

source/clear-linux/guides/maintenance/mixer.rst


-      # mixer init --git
+   sudo mixer init --clear-version 21060 --mix-version 100


Requested edit: remove sudo

kevincwells · 2018-03-06T19:09:23Z

source/clear-linux/guides/maintenance/mixer.rst


-         .. code-block:: bash
+Additionally, to build a mix with your own custom RPMs, use the optional
+ :option:`--local-rpms` flag, for example:


The leading space here makes this indent as if a tab was inserted. Is this intended?

Suggested edit: remove leading space.

Not intended, nice catch! Done

kevincwells · 2018-03-06T22:02:40Z

source/clear-linux/guides/maintenance/mixer.rst

+
+.. code-block:: bash
+
+   sudo mixer versions update --upstream-version latest


Requested edit: remove sudo

kevincwells · 2018-03-06T22:04:07Z

source/clear-linux/guides/maintenance/mixer.rst

+
+This command sets the upstream version to the latest released version of
+upstream |CL| within the same format version. The :command:`mixer
+versions update` command does not allow to set an upstream version to a


You removed the word "you", but without it, "The mixer versions update command does not allow to set" is incorrect.

Added 'you' back

kevincwells · 2018-03-06T22:06:08Z

source/clear-linux/guides/maintenance/mixer.rst

+"format bump" build, which is currently a manual process. See :ref:`mixer-format`
+for more information.
+
+Learn which mix version or upstream version you currently are on with the


Similar to my comment about mixer bundle validate, the active voice (and thus command form) here kind of loses that this is an optional step. Not strictly wrong, it just feels weird.

Added 'Optionally, you can" to communicate the fact this is optional.

kevincwells · 2018-03-06T22:06:19Z

source/clear-linux/guides/maintenance/mixer.rst

+
+.. code-block:: bash
+
+   sudo mixer versions


Requested edit: remove sudo

kevincwells · 2018-03-06T22:09:07Z

source/clear-linux/guides/maintenance/mixer.rst


-   Edit the config file to include all bundles that you want *preinstalled*
-   into your image. The rest of the bundles in your mix will be available to your users via:
+   sudo mixer bundle remove bundle1


Requested edit: remove sudo

kevincwells · 2018-03-06T22:24:38Z

@rcaballeromx Ah, I see @ECouzens just pushed a few new commits on top of yours that I was reviewing. This makes Github mark the vast majority of my edits as "outdated" (and hidden by default). Please do not miss these edits, as they are still valid.

kevincwells · 2018-03-06T22:39:53Z

@ECouzens -- I notice this branch now has a few merge commits (e.g. 888cf2f), in addition to the edit commits. I'm guessing you did a git merge into your own local copy of this branch, then pushed these commits along with your edits on accident. As is, this branch needs to be rebased to remove them. In the future, can you be sure to either pull the branch from scratch, do a git pull instead of a git merge, or manually rebase your changes before pushing them?

kevincwells · 2018-03-06T22:58:09Z

@rcaballeromx and others:

I'd like to reiterate that the review process I've observed here is not how Git (or GitHub) are supposed to be used. When I submit a pull request, the commits live on my personal branch in my personal GitHub fork repository (in this case, kevincwells/mixer-tools). In general, no one should write to this branch except me. This is not a communal branch on a communal repository like the original, it is a personal fork of that original.

If there are changes you would like before my PR can be merged, and I can reasonably make them myself, you should note the changes as part of GitHub's "Request changes" review feature. It would then be my responsibility to make those changes on my personal branch, and then push (or force-push) to update my PR.

The fact that I can (and likely will need to) force-push changes to commits should illustrate why others should not be pushing to my branch. If I am making an edit to my commit, and some other person pushes additional commits to it before I finish, I can accidentally erase them by force-pushing my update. (Yes, this is a risk any time people are sharing a branch and editing it in parallel. But again, this is not, in fact, a shared branch.)

If your team would like to instead be responsible for editing the contents of my PR, perhaps the best process would be to have developers instead submit their PR's to a "review" branch on the upstream repository. Your team could then accept the PR and merge the commits into the review branch, where you would be free to make additional commits or edit those that already exist.

rcaballeromx · 2018-03-06T23:12:19Z

@kevincwells Thank you very much for the feedback regarding this review process. In the past, we followed the process just as you described it and as Github was intended to work. However, that process creates an overhead. For example, if I review the content and comment on the changes providing the edits, you then need to implement said edits. Thus, both of us have performed the same work. I will take your feedback to our documentation team meeting and discuss alternatives and ways to avoid the issues.

rcaballeromx · 2018-03-06T23:12:53Z

@kevincwells I will not miss your edits and thank you for making all the comments in such a precise way.

Additionally, all the unnecessary sudo commands have been removed. Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>

rcaballeromx

I have addressed all your comments @kevincwells and marked them as done with further explanations where appropriate.

rcaballeromx · 2018-03-07T15:19:27Z

source/clear-linux/guides/maintenance/mixer.rst

+#. `Create an image`_
+
+Alternatively, the following workflow applies if the mix only uses |CL|
+bundles.


rcaballeromx · 2018-03-07T15:20:43Z

source/clear-linux/guides/maintenance/mixer.rst

-   specified in the builder.conf, in this case ``/home/clr/mix/mix-bundles``.
-   This is where the bundle definitions are stored for your mix, and it's where
-   the chroot-builder looks to know what bundles must be installed.
+   sudo mixer init


rcaballeromx · 2018-03-07T15:22:38Z

source/clear-linux/guides/maintenance/mixer.rst

+based on the latest released upstream |CL| version. If a :file:`builder.conf`
+file is not already present in your workspace, mixer creates a default configuration
+file along with several version and tracking files and two bundle directories:
+:file:`local-bundles` and :file:`upstream-bundles`.


I split it into two sentences to reflect that the creations are independent from each other.

rcaballeromx · 2018-03-07T15:23:38Z

source/clear-linux/guides/maintenance/mixer.rst


-         .. code-block:: bash
+Additionally, to build a mix with your own custom RPMs, use the optional
+ :option:`--local-rpms` flag, for example:


Not intended, nice catch! Done

rcaballeromx · 2018-03-07T15:23:46Z

source/clear-linux/guides/maintenance/mixer.rst


-#. **Configure builder.conf**. Edit the :file:`builder.conf` as needed.
+   sudo mixer init --local-rpms


rcaballeromx · 2018-03-07T16:35:21Z

source/clear-linux/guides/maintenance/mixer.rst

+
+.. code-block:: bash
+
+   sudo mixer versions update --upstream-version 21070


rcaballeromx · 2018-03-07T16:35:26Z

source/clear-linux/guides/maintenance/mixer.rst

+
+.. code-block:: bash
+
+   sudo mixer versions update --upstream-version latest


rcaballeromx · 2018-03-07T16:36:50Z

source/clear-linux/guides/maintenance/mixer.rst

+
+This command sets the upstream version to the latest released version of
+upstream |CL| within the same format version. The :command:`mixer
+versions update` command does not allow to set an upstream version to a


Added 'you' back

rcaballeromx · 2018-03-07T16:39:43Z

source/clear-linux/guides/maintenance/mixer.rst

+"format bump" build, which is currently a manual process. See :ref:`mixer-format`
+for more information.
+
+Learn which mix version or upstream version you currently are on with the


Added 'Optionally, you can" to communicate the fact this is optional.

rcaballeromx · 2018-03-07T16:40:01Z

source/clear-linux/guides/maintenance/mixer.rst

+
+.. code-block:: bash
+
+   sudo mixer versions


kevincwells · 2018-03-07T21:27:36Z

+1 on all of @rcaballeromx's changes -- great job!

I found a missing word (my doing) and a very minor formatting issue, and just pushed a commit that fixes both.

The only outstanding things I am aware of are the two things I'd like @tmarcu and @matthewrsj to weigh in on:

Am I correct that mixer only auto-generates the Swupd_Root.pem file if the location defined in CERT doesn't exist? @rcaballeromx made that change, but I'm not an expert on that part of the code.
Should we, in fact, be instructing people to use the --new-swupd and --new-chroots yet? Or should we just say it is optional/experimental? (Either way, the docs will need updated once those are no longer behind the --new- flags)

tmarcu · 2018-03-07T21:31:58Z

@kevincwells
1.) Yes it will only generate if the file doesn't exist.
2.) yes we should be telling people to use the new flags.

rcaballeromx

@kevincwells @tmarcu Thank you both! I am approving and merging the PR.

kevincwells force-pushed the mixer-doc-update branch from 14a9574 to 310f01d Compare January 26, 2018 20:18

rcaballeromx requested review from rcaballeromx and ECouzens January 26, 2018 20:22

ECouzens added 2 commits February 5, 2018 13:34

Merge for review

0f2d87c

Merge branch 'mixer-doc-update' of https://github.com/kevincwells/clear-linux-documentation into mixer-doc-update

Formatting and copy edit of mixer maintenance guide

5b4690f

Signed-off-by: Ecouzens <evan.couzens@intel.com>

tmarcu reviewed Feb 7, 2018

View reviewed changes

tmarcu previously approved these changes Feb 7, 2018

View reviewed changes

ECouzens previously approved these changes Feb 13, 2018

View reviewed changes

bktan8 reviewed Feb 27, 2018

View reviewed changes

bktan8 reviewed Mar 2, 2018

View reviewed changes

kevincwells force-pushed the mixer-doc-update branch from eb41287 to 19995d3 Compare March 3, 2018 00:31

rcaballeromx reviewed Mar 5, 2018

View reviewed changes

ECouzens and others added 3 commits March 5, 2018 11:29

Merge branch 'mixer-doc-update' of https://github.com/kevincwells/cle…

fe5ec7b

…ar-linux-documentation into kevincwells-mixer-doc-update

Merge branch 'mixer-doc-update' of https://github.com/kevincwells/cle…

888cf2f

…ar-linux-documentation into kevincwells-mixer-doc-update

ECouzens added 2 commits March 6, 2018 13:33

copy edit and language cleanup

c2902ec

Signed-off-by: Ecouzens <evan.couzens@intel.com>

copy edit and language update

eb26ba0

Signed-off-by: Ecouzens <evan.couzens@intel.com>

kevincwells commented Mar 6, 2018

View reviewed changes

Fix technical inaccuracies introduced by rewording.

fdbd1da

Additionally, all the unnecessary sudo commands have been removed. Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>

rcaballeromx reviewed Mar 7, 2018

View reviewed changes

Fix missing word and minor formatting issue

5f9bed0

rcaballeromx approved these changes Mar 7, 2018

View reviewed changes

rcaballeromx merged commit 31900f3 into clearlinux:master Mar 7, 2018

kevincwells mentioned this pull request Mar 15, 2018

Mixer Documentation implicit section hyperlinks not working #97

Closed

		@@ -70,211 +92,267 @@ Mixing
		VERSIONURL=<URL where the version of the mix will be hosted>
		FORMAT=1


		# mixer init --git
		sudo mixer init --clear-version 21060 --mix-version 100


		.. code-block:: bash

		sudo mixer versions update --upstream-version latest


		#. Configure builder.conf. Edit the :file:`builder.conf` as needed.
		sudo mixer init --local-rpms

Update Mixer documentation #80

Update Mixer documentation #80

Conversation

kevincwells commented Jan 26, 2018

kevincwells commented Jan 26, 2018

rcaballeromx commented Jan 26, 2018

Choose a reason for hiding this comment

ECouzens left a comment

Choose a reason for hiding this comment

matthewrsj commented Feb 14, 2018

tmarcu commented Feb 14, 2018

ECouzens commented Feb 15, 2018

tmarcu commented Feb 22, 2018

kevincwells commented Feb 22, 2018

mrkz commented Feb 27, 2018

rcaballeromx commented Feb 27, 2018

tmarcu commented Feb 27, 2018

kevincwells commented Feb 27, 2018 • edited Loading

kevincwells commented Feb 27, 2018

rcaballeromx commented Feb 27, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tmarcu commented Feb 27, 2018

bktan8 commented Feb 27, 2018

rcaballeromx commented Feb 27, 2018

kevincwells commented Feb 28, 2018

kevincwells commented Mar 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevincwells Mar 5, 2018 • edited Loading

Choose a reason for hiding this comment

rcaballeromx commented Mar 2, 2018

kevincwells commented Mar 3, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rcaballeromx commented Mar 5, 2018

kevincwells commented Mar 5, 2018

rcaballeromx commented Mar 6, 2018

kevincwells commented Mar 6, 2018

kevincwells left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevincwells commented Mar 6, 2018 • edited Loading

kevincwells commented Mar 6, 2018 • edited Loading

kevincwells commented Mar 6, 2018

rcaballeromx commented Mar 6, 2018

rcaballeromx commented Mar 6, 2018

rcaballeromx left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevincwells commented Feb 27, 2018 •

edited

Loading

kevincwells Mar 5, 2018 •

edited

Loading

kevincwells commented Mar 6, 2018 •

edited

Loading

kevincwells commented Mar 6, 2018 •

edited

Loading

kevincwells commented Mar 7, 2018 •

edited

Loading