I found several problem with Confluence:
1.It's impossible to update document in batch
2.People without apache account can't modify the document
3.It's hard to add review process before applying the change
4.Newbie can't easily find all documents
If we move all documents to https://github.com/apach
Versioning is important but I think that the most important reason to keep the
docs in the repositories is because we have a visible, manageable process to
update critical documents via PRs. For example,changes to the coding standard
need careful review and approval.Sent from Samsung tablet.
nu
On Mon, Jul 20, 2020 at 4:32 PM Justin Mclean
wrote:
> That's a great idea, but it may have some impact on teh LICENSE file
> depending on what libraries, fonts etc are bundled with the documentation.
> You may need to make sure that nothing with an incomparable license sneaks
> in.
>
The curren
Hi,
> I also love having the docs in the repository and releases, and versioned
> along with the code. It makes things so much easier.
That's a great idea, but it may have some impact on teh LICENSE file depending
on what libraries, fonts etc are bundled with the documentation. You may need
to
I also love having the docs in the repository and releases, and versioned
along with the code. It makes things so much easier.
If I had to pick between the current docs (HTML/txt) and the wiki, I would
pick the current docs!
-adam
On Mon, Jul 20, 2020 at 4:17 PM Nathan Hartman
wrote:
> On Mon,
On Mon, Jul 20, 2020 at 7:07 PM Gregory Nutt wrote:
> For those really opposed to HTML, another option is to simply use the
> Confluence versions of the documents here:
> https://cwiki.apache.org/confluence/display/NUTTX/Documentation
>
> These are the same documents that are currently in nuttx/D
For those really opposed to HTML, another option is to simply use the
Confluence versions of the documents here:
https://cwiki.apache.org/confluence/display/NUTTX/Documentation
These are the same documents that are currently in nuttx/Documentation.
They are read-only now (since the master is
I will do a PR to your branch and repo, but will you create a branch
and put your changes on it? The branch should be called something like
feature/sphinx-docs.
If you do that, I can do PR directly to that branch. Having it on a
branch other than master will make it easier to submit later,
Hi guys. In the meantime, I carefully converted most of the readmes in
the `apps` repository. Four folders left
- [x] main readme
- [x] netutils
- [x] wireless
- [x] examples
- [x] modbus
- [x] fsutils
- [x] gpsutils
- [ ] testing
- [ ] system
- [x] tools
- [x] industry
- [x] interpreters
- [
> Sure. I created a "docs" branch on https://github.com/v01d/incubator-nuttx/
> I'm mostly experimenting right now anyways. Should we wait for an official
> vote to confirm we're heading
> in the right direction? Migrating documentation also will require some
> coordination to avoid introducing
Thanks Matias.
Following Matias' proposal, here's a separate repo with just one page of
the HTML docs partially converted:
https://github.com/adamfeuer/nuttx-docs
The files here could also be copied into a directory in the nuttx source
tree too, for instance under Documentation/sphinx-docs inste
+1
Maintaining code coherency (including docs) is YUUGely more difficult
when separate repos are involved.
If the main reason for creating a second repo is to more cleanly have
two doc directories maybe Markdown isn't the answer you want anyway.
If the focus on pretty print is to use RST the
Can we keep the doc and nuttx in one git? The major of document is normally
couple with the code. The separation make the
synchronization between code and document more harder. Other similar
project(e.g. Linux and Zephyr) use the same git manage both
code and document:
https://github.com/torvalds
13 matches
Mail list logo
