-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs_devel: update contribution manual about document build and others #908
docs_devel: update contribution manual about document build and others #908
Conversation
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Remove duplication with the contribution guide, and replace with links to the guide Signed-off-by: Hiroshi Miura <miurahr@linux.com>
There are almost a technology side of document build, not about contribution rules and procedures. A missing part is a build property option to skip html manual build when building and testing features. |
@miurahr There's a lot of material in the developer documentation, so I'm going to wait until I can set aside a good chunk of time to do a proper review, which probably means sometime early in April, when work gets quieter. Until then, I think we can still push the updates as is (maybe with a DRAFT label) to make information available. (It'll also be easier to review if it's up on the @brandelune What do you think? |
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
There is very small section about a document contribution rule and procedure |
Please contact to [Documentation manager](https://omegat.org/about) at [omegat-development mailing list] | ||
(https://sourceforge.net/projects/omegat/lists/omegat-development) for details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a space character between link text and url
Please contact to [Documentation manager](https://omegat.org/about) at [omegat-development mailing list] | |
(https://sourceforge.net/projects/omegat/lists/omegat-development) for details. | |
Please contact to [Documentation manager](https://omegat.org/about) at [omegat-development mailing list](https://sourceforge.net/projects/omegat/lists/omegat-development) for details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would people need to contact the documentation manager ? People can do as they do for the code. Send PRs after creating issues on SF, on the documentation tracker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because I cannot find any document to describe rules and procedure in omegat.org website, and also in source tree. Please give a description. Otherwise, I can revert it to previous sentence; "[TBD]".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be valuable to add from https://omegat.org/support
documentation issues are handled on SourceForge by the Documentation tracking system. Please do not use these tracking systems before first raising the issue on the user group and/or mailing lists.
A few rewording suggestions.
Various changes. I put comments preceded by "->".
Few more fixes.
I removed most of the promotion for Docker and restructured the document a bit. I think most of the last part is irrelevant now that we use containers. I've added comments prefixed with "->".
Added reference to contribution rules, etc.
Add the link to Kos' explanations.
Small modifications
Various small fixes and a comment (check "->")
Fix typo and slight rewording.
# Fonts | ||
|
||
-> Aren't the fonts installed in the container? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They should be. This would apply to building the documentation without using a container, which requires the user to manually install all font and software dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, and if we still have the possibility to make manual build, I don't understand why we have a container requirement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should probably be called a container option.
In theory, a container makes building the documentation easier than the manual process because it… well… contains everything!
Something strange seems to be going on with the manual build process, though. I'm getting everything inside a literal ${target}
directory in doc_src\en\
instead of in the correct docs\en\
folder if I try to build with Ant. More investigation required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something strange seems to be going on with the manual build process, though. I'm getting everything inside a literal
${target}
directory indoc_src\en\
instead of in the correctdocs\en\
folder if I try to build with Ant. More investigation required.
OK. It looks like building the documentation manually now requires passing both the -Dtarget
and the -Dlanguage
arguments to Ant.
I'm not sure why it didn't need to be passed explicitly before but is necessary now.
I think it might be a good idea to split this file into separate "using a container to build the documentation" and "building the documentation manually" files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be a good idea to split this file into separate "using a container to build the documentation" and "building the documentation manually" files.
I agree. Thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will work it.
|
||
### License | ||
|
||
All the files in `doc_src` folder and below are under the terms of the GNU General | ||
All the files in `doc_src` folder and below are published under the terms of the GNU General |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@brandelune
I'm not a licence expert, but do software licenses apply to documentation?
Should this be one of the Creative Commons licenses?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GPL is not specifically a software licence. It is a source code distribution licence. Our docbook sources are not supposed to have issues that can only be solved by using documentation specific licences. But if you find such issues, we need to investigate how to fix them, because changing the licence would be a major pain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If XML is considered code, then there's probably no problem because the docbook sources can be defined as "source code".
I'll trust that whoever first chose the licence checked this at the time! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally, the manual was in HTML. There was no build process involved. The whole set was distributed under the GPL, and it just stayed like that. The Emacs manuals use the GFDL 1.3+ which makes sense, if I remember well, because they can also be distributed as books (cf. invariant clauses, etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting.
I found this interesting thread that's relevant.
If I understand it correctly, GPL for the docbook sources is fine. The actual manual(s) produced from those sources should probably be under the GFDL or one of the Creative Commons licences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understood the thread (and GNU GPL FAQ) correctly, licensing the actual manual (output HTML, PDF, etc.) under the GPL would require including the contents of doc_src
with the manual itself, which I think would be (a) cumbersome for us, and (b) tedious for users.
Of course, I might simply be misunderstanding the answers in the thread and FAQ.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FSF recommend GFDL for document rather than GPL in several reason.
https://www.gnu.org/licenses/license-recommendations.html
It is something extra-ordinal to apply GPL to a large manual document like OmegaT manual, so I try to add explanation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that our choice of licence may not be the best, but we currently do not have issues that need to be solved by a change of licence.
It could be a fun exercise to track down the various authors that share the copyright on the current document though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the statement in the developer documentation here only applies to the docbook sources, so as far as those go, I think the developer documentation is fine as is in terms of contents.
The broader licensing issue may (or may not) be something to look at further down the road in the larger context of the entire project.
Have we explicitly applied the GPL (or any other licence) to the products output from those sources?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GPL applies to the deliverables (the "program") and forces the developers to provide sources on demand so that users can modify the deliverable. The GPL is not a source file distribution licence.
Wording change, because documentation isn't really "developed". :)
Wording tweaks.
Various wording tweaks.
licensing the actual manual (output HTML, PDF, etc.) under the GPL would require including the contents of doc_src with the manual itself, which I think would be (a) cumbersome for us, and (b) tedious for users.
The requirement is only and minimally access to the code upon request. Which we do by default since the code is always available. Just like we do not distribute the OmegaT code with the binaries but keep it available online.
|
Rewording of section on building Linux native packages using `jpackage`
Co-authored-by: Hiroshi Miura <miurahr@linux.com>
Signed-off-by: Hiroshi Miura <miurahr@linux.com>
Now all the reviewer feedback to be fixed are resolved. |
omegat-org#908) * docs_devel: update document contribution manual Signed-off-by: Hiroshi Miura <miurahr@linux.com> * docs_devel: Fix link URLs Signed-off-by: Hiroshi Miura <miurahr@linux.com> * docs_devel: Split manual contribution guide and build manual Signed-off-by: Hiroshi Miura <miurahr@linux.com> * docs: update doc_src/Readme.md Remove duplication with the contribution guide, and replace with links to the guide Signed-off-by: Hiroshi Miura <miurahr@linux.com> * docs_devel: explain about build task and how to skip manual generation Signed-off-by: Hiroshi Miura <miurahr@linux.com> * Update Readme.md A few rewording suggestions. * Update 02.HowToBuild.md Various changes. I put comments preceded by "->". * Update 02.HowToBuild.md Few more fixes. * Update 07.ManualContainerTaskBuild.md I removed most of the promotion for Docker and restructured the document a bit. I think most of the last part is irrelevant now that we use containers. I've added comments prefixed with "->". * Update 40.ContributingDocument.md Added reference to contribution rules, etc. * Update 45.LocalizeApplicationAndManuals.md Add the link to Kos' explanations. * Update 92.CodeSigning.md Small modifications * Update 93.BuildingInstallerPackage.md Various small fixes and a comment (check "->") * chore: Update 02.HowToBuild.md * chore: Update 02.HowToBuild.md Fix typo and slight rewording. * chore: Update 40.ContributingDocument.md Wording change, because documentation isn't really "developed". :) * chore: Update 45.LocalizeApplicationAndManuals.md Wording tweaks. * chore: Update 92.CodeSigning.md * chore: Update 93.BuildingInstallerPackage.md Various wording tweaks. * chore: Update 93.BuildingInstallerPackage.md Rewording of section on building Linux native packages using `jpackage` * chore: Apply suggestions from code review Co-authored-by: Hiroshi Miura <miurahr@linux.com> * chore: Delete resolved inline comment in 93.BuildingInstallerPackage.md * docs_devel: split document build manual Signed-off-by: Hiroshi Miura <miurahr@linux.com> --------- Signed-off-by: Hiroshi Miura <miurahr@linux.com> Co-authored-by: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> Co-authored-by: kazephil <kazephil@gmail.com>
Pull request type
Which ticket is resolved?
What does this PR change?
Other information