Convert doc folder files to doxygen

doxygen/dox/TechnicalNotes.dox

@@ -3,18 +3,25 @@
 \li \ref api-compat-macros
 \li \ref APPDBG
 \li \ref FMTDISC
+\li \ref BRANCHEXPL
+\li \ref CODECONV
 \li \ref sec_file_image
 \li \ref subsubsec_dataset_transfer_filter
+\li \ref FileLock
+\li \ref InitShut
 \li \ref IOFLOW
+\li \ref ParCompr
 \li \ref TNMDC
 \li \ref thread-safe-lib
 \li \ref SWMRTN
+\li \ref ThrdSafe
 \li \ref VDSTN
 \li \ref RELVERSION
 \li \ref UNICODE
 \li \ref VFLTN
 \li <a href="https://github.com/HDFGroup/arch-doc/blob/main/An_Overview_of_the_HDF5_Library_Architecture.v2.pdf">HDF5 Library Architecture Overview</a>
 \li \ref VOL_Connector
+\li \ref CMakeVols
 
  */
 

doxygen/dox/branches-explained.dox

@@ -0,0 +1,63 @@
+/** \page BRANCHEXPL HDF5 Git Branching Model Explained
+
+This document describes current HDF5 branches. 
+
+Branches are tested nightly and testing results are available at
+https://my.cdash.org/index.php?project=HDF5. 
+Commits that break daily testing should be fixed by 3:00 pm Central time or reverted.  
+We encourage code contributors to check the status of their commits. If you have any questions,
+please contact [email protected].
+
+\section sec_branchexpl_develop develop branch
+Develop is the main branch whose source code always reflects a state with the latest delivered
+development changes for the next major release of HDF5. 
+This is also considered the integration branch, as \b all new features are integrated into this
+branch from respective feature branches. Although
+develop is considered an integration branch, it is not an unstable branch. All code merged to
+develop is expected to pass all GitHub actions and daily tests.
+
+\section sec_branchexpl_maintenace Maintenance branches
+Each currently supported release line of HDF5 (e.g. 1.8.x, 1.10.x, 1.12.x, 1.14.x) has an associated
+branch with the name hdf5_1_10, etc.. 
+Maintenance branches are similar to the develop branch, except the source code in a maintenance
+branch always reflects a state 
+with the latest delivered development changes for the next \b maintenance release of that particular
+supported release-line of HDF5. 
+\b Some new features will be integrated into a release maintenance branch, depending on whether or
+not those features can be 
+introduced in minor releases.  Maintenance branches are removed when a release-line is retired from
+support.
+
+\section sec_branchexpl_release Release branches
+Release branches are used to prepare a new production release. They are primarily used to allow for
+last minute dotting of i's and crossing of t's 
+(things like setting the release version, finalizing release notes, and generating Autotools files)
+and do not include new development. 
+They are created from the maintenance branch at the time of the maintenance release and have 
+names like hdf5_1_10_N, where N is the minor release number. Once the release is  done it is
+tagged, with a slightly different format: hdf5-1_10_N. 
+Release branches are deleted after the tag has been created. If we have to create a patch version
+of a release (which is rare), we create a branch off of the tag.
+
+\section sec_branchexpl_feature feature/\*
+Feature branches are temporary branches used to develop new features in HDF5.
+Feature branches branch off of develop and exist as long as the feature is under development. 
+When the feature is complete, the branch is merged back into develop, as well as into any support
+branches in which the change will be included, and then the feature branch is removed.
+
+Ideally, all feature branches should contain a BRANCH.md file in the root directory that explains
+the purpose of the branch, contact information for the person responsible, and, if possible, some
+clues about the branch's life cycle (so we have an idea about when it can be deleted, merged, or
+declared inactive).
+
+Minor bug fixes and refactoring work usually takes place on personal forks, not feature branches.
+
+\section sec_branchexpl_inactive inactive/\*
+These branches are for experimental features that were developed in the past, have not been merged
+to develop, and are not under active development. The exception to this is that some feature branches
+are labeled inactive and preserved for a short time after merging to develop. Integration branches
+are usually not kept in sync with the develop branch.
+
+As for feature branches, inactive branches should have a BRANCH.md file as described above.
+
+*/