Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2018-03-27T14:09:26Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2312Issues to be address before making automated PR testing and merging mandatory2018-03-27T14:09:26ZJames WillenbringIssues to be address before making automated PR testing and merging mandatory*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @rppawlo, @maherou, @srajama1
## Description:
There has been recent discussion about when the time to make automated PR testing and merging system being developed by the @t...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @rppawlo, @maherou, @srajama1
## Description:
There has been recent discussion about when the time to make automated PR testing and merging system being developed by the @trilinos/framework team mandatory. From my own experience and conversations with other people, the following issues would need to be addressed before that can occur:
* Update and streamline the builds used by the automated PR testing system (to make sure that we are getting the needed testing, having the builds not take too many computer resoruces, and getting the biggest bang for our buck in protecting important functionality.) (see #2317)
* **STATUS:** ???
* Post all build results to CDash to see exactly what is getting tested and what the failures are (and allow it to be reviewed before the final merge).
* Complete the upgrade of the new CDash version that supports all-at-once configure, build, test, and submit (see https://gitlab.kitware.com/snl/project-1/issues/33).
* **STATUS:** Currently, the PR build results are being submitted to the trial testing-vm.sandia.gov/cdash site and the Framework team is okay with the stability of that site for managing PR builds so this is not currently considered an impediment.
* Upgrade the minimum version of CMake used by Trilinos from 2.8.11 to 3.10 in order to take advantage of all-at-once configure, build, test, and submit to new CDash version. (Also, once the auto PR testing is using CMake 3.10 it will allow CMake code in packages that does not work with older versions of CMake and therefore will destabilize other builds of Trilinos unless we force the upgrade).
* **STATUS:** This can be done later. For now, this might allow CMakeLists.txt files to get pushed that will break the configure of Trilinos with older CMake versions but the current post-push CI build and other nightly builds would catch that.
* Make it easy and obvious how to reproduce the exact auto PR builds and results shown on CDash and to allow people to run these locally even **before** they post their PR if they would like (e.g. #2295)
(Which includes making the env and/or machine accessible to all Trilinos developers, see https://github.com/trilinos/Trilinos/issues/2317#issuecomment-369987520.)
* **STATUS:** ???
* Auto-merge with final staged testing before merge to ‘develop’ (i.e. avoid violations of the [additive test assumption of branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.d1jneh8ubsyn) that resulted #2264).
* **STATUS:** Currently plan is to mark older PRs as "Stale" but not strictly guarantee stability of 'develop' due to violations of the "additive test assumption of branches"?
* Auto wiping the build directory when requested so that it will deal with cases where you need to build from scratch (e.g. when Panzer files get update such as described in https://github.com/trilinos/Trilinos/issues/1304#issuecomment-355786180 and https://github.com/trilinos/Trilinos/issues/1304#issuecomment-356053919).
* **STATUS:** Currently a complete build from scratch with each PR build is being done to address this. With this implementation, this is not an impediment.
* Address cases where no packages get enabled and therefore no tests are run. Will the auto PR system mark them as "passed" and allow the PR to be merged?
* **STATUS:** ???
* Document the PR and auto testing process so people can understand how to use it correctly and understand why it is firing off tests in some cases and not in other cases.
* **STATUS:** ???
* Ensure the current testing infrastructure will scale when everyone is required to use topic branches for pushing anything (even documentation changes). For example, will this scale when there are 20 active PRs being edited at the same time? When there are more and more topic branches, how long with the lags be before things get tested and eventually merged?
* **STATUS:** This will be addressed by "Update and streamline the builds used by the automated PR testing system" above?
Other issues that should be resolve (quickly) after initial adoption:
* Remove manual updates of the list of packages from mapping of directories to packages. (e.g. use self-maintaining existing code in TriBITS tools for that?). If you don’t things will not get tested correctly without manual intervention to constantly keep that manual list up to date.
The motivation for this issue was conversations with @rppawlo, @jwillenbring and the [2018-02-28 Trilinos Planning meeting](https://docs.google.com/document/d/1JClLSR3n79XJT_yLPPoQv_e3rJToHxl8fUzRYojtY5Y/edit)
## Related Issues
* Related to: #1154, #1304
* Composed of: #2317
## Tasks:
1. Define the set of builds to be used in the auto PR system with a working group (#2317). See #2317 ...
1. Complete and robustify the submitting of results to CDash (there is a start to this but it is having problems, see https://github.com/trilinos/Trilinos/pull/2310#issuecomment-369390502).
1. ???
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/2295Can the checkin script be used to test/push a branch to fork of Trilinos2018-02-26T17:06:38ZJames WillenbringCan the checkin script be used to test/push a branch to fork of Trilinos*Created by: jhux2*
Question: Can the checkin script be used to test and push a branch on a fork of Trilinos, and if so, what's the procedure for setting this up?
__Context__
I would like to use the checkin script to test changes in...*Created by: jhux2*
Question: Can the checkin script be used to test and push a branch on a fork of Trilinos, and if so, what's the procedure for setting this up?
__Context__
I would like to use the checkin script to test changes in a local branch within my fork of Trilinos. If all tests pass, ideally the script would then automatically push the branch to my fork. After that, I would issue a pull request against trilinos/Trilinos.
@trilinos/framework @bartlettroscoe
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2292Trilinos "Clean" and auto PR builds need a Trilinos_ENABLE_DEBUG=ON build2018-05-30T18:37:02ZJames WillenbringTrilinos "Clean" and auto PR builds need a Trilinos_ENABLE_DEBUG=ON build*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou, @rppawlo
## Description
It would seem that all of the current "Clean" builds of Trilinos shown for example yesterday at:
* https://testing.sandia.gov/cdash/in...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @maherou, @rppawlo
## Description
It would seem that all of the current "Clean" builds of Trilinos shown for example yesterday at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&date=2018-02-21&filtercount=1&showfilters=1&field1=groupname&compare1=61&value1=Clean
all have `Trilinos_ENABLE_DEBUG=OFF` set. You can see this, for example, by looking at the uploaded CMakeCache.txt files for these three builds at:
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3398366##note0
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3398237##note3
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3398203##note3
which all show:
```
Trilinos_ENABLE_DEBUG:BOOL=OFF
```
This is not a good thing because there are a lot of run-time checks turned on with you configure Trilinos with `-DTrilinos_ENABLE_DEBUG=ON`. It catches a lot of undefined and otherwise illegal behavior that a `Trilinos_ENABLE_DEBUG=OFF` does not catch.
Because none of the "Clean" builds have `-DTrilinos_ENABLE_DEBUG=ON` one would assume that none of the auto PR builds have it set either. Therefore, can that auto PR builds have at least one build that has this turned on. And from looking at recent PRs like:
* https://github.com/trilinos/Trilinos/pull/2289#issuecomment-367782068
it looks like the auto PR tester is now only running one build. If that is the case, it is critical that this one build set `-DTrilinos_ENABLE_DEBUG=ON`.
This is a big issue for supporting developers and users of Trilinos and especially for ATDM builds of Trilinos that set `-DTrilinos_ENABLE_DEBUG=ON`. For example, this let skip through defects like #2270.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2231Framework: Update License Information2018-02-08T22:21:18ZJames WillenbringFramework: Update License Information*Created by: csiefer2*
The license information given below is for 11.8/11.14:
https://trilinos.org/download/license/
Can we update this information to the latest release?
@jwillenbring *Created by: csiefer2*
The license information given below is for 11.8/11.14:
https://trilinos.org/download/license/
Can we update this information to the latest release?
@jwillenbring https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2221Pamgen,kokkos-kernels: NVCC build error with -D CMAKE_CXX_USE_RESPONSE_FILE_F...2019-03-05T22:14:10ZJames WillenbringPamgen,kokkos-kernels: NVCC build error with -D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON*Created by: mhoemmen*
kokkos-kernels requires `-D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON` for CUDA builds, even with complex arithmetic disabled.
https://github.com/trilinos/Trilinos/issues/2115#issuecomment-357750048
However...*Created by: mhoemmen*
kokkos-kernels requires `-D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON` for CUDA builds, even with complex arithmetic disabled.
https://github.com/trilinos/Trilinos/issues/2115#issuecomment-357750048
However, Pamgen does not build, given those settings.
@trilinos/kokkos-kernels @trilinos/pamgen @trilinos/framework
CC: @rrdrake @prwolfe
## Expectations
1. Whatever flags kokkos-kernels needs to build on CUDA, they need not to block building other essential packages.
2. kokkos-kernels needs to document its CMake requirements.
3. kokkos-kernels needs to fail at configure time, with an informative message, if the CMake variables that it needs are not set.
## Current Behavior
```
$ make
[ 0%] Linking CXX shared library libpamgen.so
nvcc fatal : No input files specified; use option --help for more information
make[2]: *** [packages/pamgen/src/libpamgen.so.12.13] Error 1
make[1]: *** [packages/pamgen/src/CMakeFiles/pamgen.dir/all] Error 2
make: *** [all] Error 2
```
## Motivation and Context
Many downstream tests, including Belos and Ifpack2, depend on Pamgen. This blocks adequate Trilinos testing on CUDA.
## Steps to Reproduce
```
$ module list
Currently Loaded Modulefiles:
1) sems-env 3) sems-cmake/3.3.2 5) kokkos-cuda/8.0.44
2) kokkos-env 4) sems-gcc/5.3.0 6) kokkos-openmpi/2.0.1/cuda
```
CMake configuration:
```
-D Trilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON
-D BUILD_SHARED_LIBS:BOOL=ON
-D Trilinos_ENABLE_OpenMP:BOOL=ON
-D Kokkos_ENABLE_OpenMP:BOOL=ON
-D Tpetra_INST_OPENMP:BOOL=ON
-D Trilinos_SHOW_DEPRECATED_WARNINGS:BOOL=ON
-D Trilinos_ENABLE_Fortran:BOOL=OFF
-D TPL_ENABLE_CUDA:BOOL=ON
-D KOKKOS_ARCH="SNB;Kepler35"
-D Kokkos_ENABLE_Cuda:BOOL=ON
-D Kokkos_ENABLE_Cuda_UVM:BOOL=ON
-D Tpetra_INST_CUDA:BOOL=ON
-D Kokkos_ENABLE_Cuda_Lambda:BOOL=ON
-D CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS:BOOL=ON
-D CMAKE_CXX_FLAGS:STRING="-Wall"
-D Trilinos_CXX11_FLAGS:STRING="-std=c++11 --expt-extended-lambda"
-D TPL_ENABLE_MKL:BOOL=OFF
-D TPL_ENABLE_Matio:BOOL=OFF
-D TPL_ENABLE_SuperLU:BOOL=OFF
-D TPL_ENABLE_Zlib:BOOL=OFF
-D TPL_ENABLE_Netcdf:BOOL=OFF
-D TPL_ENABLE_HDF5:BOOL=OFF
-D TPL_ENABLE_ParMETIS:BOOL=OFF
-D TPL_ENABLE_Boost:BOOL=OFF
-D TPL_ENABLE_BoostLib:BOOL=OFF
-D TPL_ENABLE_yaml-cpp:BOOL=OFF
-D TPL_ENABLE_MPI:BOOL=ON
```
## Your Environment
- develop branch, commit 400765e21e17dfb995e0f4a2759ce9c5f961b685 (likely not related)
## Related Issues
* Blocks #2115 https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2174Request for a windows nightly build for the Tpetra stack2018-03-09T23:43:55ZJames WillenbringRequest for a windows nightly build for the Tpetra stack*Created by: bmpersc*
@trilinos/framework @trilinos/kokkos @trilinos/tpetra @trilinos/belos @trilinos/muelu
@xyshal @wppowers
The Kokkos issue at kokkos/kokkos#1313 has had some discussion about windows and the tpetra stack. Since ...*Created by: bmpersc*
@trilinos/framework @trilinos/kokkos @trilinos/tpetra @trilinos/belos @trilinos/muelu
@xyshal @wppowers
The Kokkos issue at kokkos/kokkos#1313 has had some discussion about windows and the tpetra stack. Since the testing in question is really beyond the scope of just Kokkos and more of a Trilinos issue we should move any further discussion here.
I have added the package teams that were explicitly mentioned in the Kokkos issue. However, there are probably more packages that would be involved since Muelu has quite a few dependencies.
The Trilinos Framework does have an existing windows test machine that has free cycles so we have hardware to support this. What we are lacking is a driver and buy in from the package teams to support such a build.
What we would need to know is what kind of testing is expected and what kind of support is expected for a windows build.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2160CMake 2.8.12 thinks Intel 15.0.2 build is actually 15.0.0.20150121 and is not...2018-01-29T23:49:04ZJames WillenbringCMake 2.8.12 thinks Intel 15.0.2 build is actually 15.0.0.20150121 and is not supported by Kokkos*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/kokkos
## Description
I was looking over the Intel builds for Trilinos as part of #2142 and I noticed that the build [Linux-intel-15.0.2-MPI_RELEASE_DEV_DownStrea...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/kokkos
## Description
I was looking over the Intel builds for Trilinos as part of #2142 and I noticed that the build [Linux-intel-15.0.2-MPI_RELEASE_DEV_DownStream_ETI_SERIAL-OFF_OPENMP-ON_PTHREAD-OFF_CUDA-OFF_COMPLEX-OFF build](https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=3329931) that claims to be for Intel 15.0.2 is actually Intel 15.0.0.20150121 and that version is **not** supported by Kokkos as shown in the [configure output](https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3329935):
```
- CMAKE_VERSION='2.8.12.2'
[...]
-- MPI_EXEC='/projects/sems/install/rhel6-x86_64/sems/compiler/intel/15.0.2/openmpi/1.8.7/bin/mpiexec'
-- MPI_EXEC='/projects/sems/install/rhel6-x86_64/sems/compiler/intel/15.0.2/openmpi/1.8.7/bin/mpiexec'
-- CMAKE_C_COMPILER_ID='Intel'
-- CMAKE_C_COMPILER_VERSION='15.0.0.20150121'
-- CMAKE_CXX_COMPILER_ID='Intel'
-- CMAKE_CXX_COMPILER_VERSION='15.0.0.20150121'
CMake Error at packages/kokkos/cmake/kokkos_functions.cmake:72 (message):
Compiler not supported by Kokkos. Required compiler versions:
Clang 3.5.2 or higher
GCC 4.8.4 or higher
Intel 15.0.2 or higher
NVCC 7.0.28 or higher
PGI 17.1 or higher
Call Stack (most recent call first):
cmake/ProjectCompilerPostConfig.cmake:13 (set_kokkos_cxx_compiler)
/home/jenkins/slave/workspace/Kokkos_Trilinos_packages/Trilinos/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1820 (INCLUDE)
/home/jenkins/slave/workspace/Kokkos_Trilinos_packages/Trilinos/cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
/home/jenkins/slave/workspace/Kokkos_Trilinos_packages/Trilinos/cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:93 (TRIBITS_PROJECT)
-- Configuring incomplete, errors occurred!
```
This configure failure for Kokkos disables Kokkos in all downstream packages and as a result of Kokkos being disabled (and Teuchos being disabled as well due to #2128), the only packages that build any libraries and tests and run any tests are Sacado, Epetra, and Zoltan.
And the problem seems to be that SEMS thinks this is actually Intel 15.0.2 given the SEMS TPL paths like shown in the configure output above that shows the path `/projects/sems/install/rhel6-x86_64/sems/compiler/intel/15.0.2/[...]`.
## Related Issues
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to: #2142
* Part of
* Composed of
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2150Trilinos Doxygen Guidelines?2019-04-03T07:42:17ZJames WillenbringTrilinos Doxygen Guidelines?*Created by: jmgate*
@trilinos/framework
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
It'd be great if Trilinos had some...*Created by: jmgate*
@trilinos/framework
## Expectations
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
It'd be great if Trilinos had some general Doxygen guidelines for developers to follow when documenting the code they write. Has this ever been considered before?
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
We already have [this Doxygen wiki page](https://github.com/trilinos/Trilinos/wiki/Tools-%7C-Doxygen), but it focusses on how to use Doxygen to automatically generate the documentation for your package. What it doesn't say anything about, though, is what is recommended in terms of documentation in header files of classes, namespaces, functions, data, etc.
I realize Trilinos has historically left matters like this up to the individual packages to decide. Fair enough, but it seems the Trilinos community might be better served if there were some general guidelines from on high that package maintainers could then modify as they see fit.
## Motivation and Context
<!---
How has this expectation failure affected you? What are you trying to
accomplish? Why do we need to address this? What does it have to do with
anything? Providing context helps us come up with a solution that is most
useful in the real world.
-->
I come across *way* too much undocumented code on a regular basis. I imagine that's largely due to work being done quick and dirty in a fast-paced research environment—*c'est la vie*. I'd guess the problem is also compounded by the number of short-term developers (interns/postdocs/etc.) we have working on Trilinos. Left unaddressed, the problem will just continue to get worse.
I'm not saying we should drop everything, go back, and document everything that's been left undocumented over the years—actually I just might say that if you pressed me on it. I am saying it'd be awful nice to have some guidelines in place such that new code that gets added is heading us in the right direction.
## Definition of Done
<!---
Tell us what needs to happen. If necessary, give us a task lisk along the
lines of:
-->
- [ ] Figure out if Trilinos should have such guidelines.
- [ ] If so, figure out where they should live.
- [ ] Figure out what should be in them.
- [ ] Get them out there.
- [ ] Point Trilinos developers to them.
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Here are some Doxygen guidelines I whipped up recently for one of the applications I'm on, modified slightly to apply to Trilinos.
<details>
<summary>
<b>Sample Doxygen Guidelines</b> (click to expand)
</summary>
<br>
Trilinos uses [Doxygen](http://www.stack.nl/~dimitri/doxygen/index.html) to generate documentation from annotated source code.
# Documenting a Class or Struct
> **Note:** The documentation of a `struct` is the same as that required for a `class` as they are essentially the same thing, differing only in the default visibility of their members.
## The Class Itself
Classes should be preceded by a comment block along these lines:
```c++
/**
* \brief A brief description of the class goes here. The brief description
* is terminated by a blank line.
*
* The detailed description of the class follows the blank line. This should
* give an unfamiliar developer enough information to understand the purpose
* of the class and how to interact with instantiations of it via the methods
* that will be defined below.
*
* If a detailed description continues over multiple paragraphs, separate
* paragraphs with a blank line.
*/
template<stuff>
class ClassName
:
public BaseClass<stuff>
{
// Insert class definition here.
} // end of class ClassName
```
## Functions
Within the class definition, functions should be preceded by a comment block along these lines:
```c++
/**
* \brief A brief description of the function goes here. The brief
* description is terminated by a blank line.
*
* The detailed description of the function follows the blank line. This
* should give an unfamiliar developer an understanding of what the function
* is doing and why you would use it.
*
* \note If anything is noteworthy, feel free to include that here. Perhaps
* you might mention how this compares to another function in the class,
* if it is to be preferred over another method, if it has been
* deprecated and should no longer be used, etc. Similar commands you
* can use in this manner are `\remark` and `\warning`.
*
* \param[in,out] arg1 This is a description of `arg1`. This variable is used
* as both input and output; that is, its value changes
* and persists after the function call.
* \param[out] arg2 This is a description of `arg2`. This variable is used
* as output; its value when the function begins is
* irrelevant.
* \param[in] arg3 This is a description of `arg3`. Be sure to mention
* that it's inclusion is optional, and if omitted, what
* the default value is.
*
* \pre This is some precondition that must be satisfied before the function
* executes.
*
* \post This is some postcondition that will be satisfied after the function
* executes.
*
* \throws ExceptionType This is a description of why `ExceptionType` would be
* thrown in the midst of the function execution.
*
* \returns This is a description of what the function returns on completion,
* if anything.
*/
returnType
functionName(
someType arg1,
anotherType arg2,
yetAnotherType arg3 = someDefaultValue);
```
If any of the lines in the comment block above (`\note`, `\warning`, `\param`, `\throws`, `\returns`) are not applicable to the function you're documenting, simply omit them.
## Member Data
Member data should be preceded by a comment block along these lines:
```c++
/**
* \brief A brief description of the data goes here. The brief description
* is terminated by a blank line.
*
* The detailed description of the data follows the blank line. If the brief
* description gives enough information to understand the variable, its use
* and purpose, then a detailed description may not be necessary.
*/
DataType
member_data_;
```
## Enumerations
When documenting an `enum`, use something along the lines of the following:
```c++
/**
* \brief A brief description of the enum goes here. The brief
* description is terminated by a blank line.
*
* The detailed description of the enum follows the blank line. This should
* give an unfamiliar developer an understanding of what the enum represents
* and how it is used.
*/
enum EnumName
{
SOMETHING, /*!< This is a description of the SOMETHING value of the enum.
It can be as detailed as you like. */
SOMETHING_ELSE /*!< This is a description of SOMETHING_ELSE. */
}; // end of enum EnumName
```
## Typedefs and Usings
When documenting a `typedef`, the syntax is essentially the same as that used for member data:
```c++
/**
* \brief A brief description of the typedef goes here. The brief
* description is terminated by a blank line.
*
* The detailed description of the typedef follows the blank line. If the
* brief description gives enough information to understand the typedef, its
* use and purpose, then a detailed description may not be necessary.
*/
typedef OriginalType NewName;
```
However, as of C++11, we should really be phasing out `typedef`s in favor of `using` statements. Unfortunately, Doxygen has not been updated to support those out of the box, so it needs a little help. We can use the `\var` command to tell Doxygen to document a `using` statement as if it were a variable:
```c++
/**
* \var NewName
*
* \brief A brief description of the using statement goes here. The brief
* description is terminated by a blank line.
*
* The detailed description of the using statement follows the blank line.
* If the brief description gives enough information to understand the
* using statement, then a detailed description may not be necessary.
*/
using NewName = OriginalType;
```
## Grouping Entities
You may find it useful to group certain functions, variables, etc., together into named sections, particularly if your class contains a great many members. This can aid in understanding the design and intended use of the class. To group entities together in the documentation, use the following:
```c++
//-----------------------------------------------------------------------------
/* */
/** \name Group 1 Name */
/** @{ */
//-----------------------------------------------------------------------------
// Insert functions, variables, typedefs, etc., here, along with their
// documentation.
//-----------------------------------------------------------------------------
/** @} */
/* end of Group 1 Name */
/* */
//-----------------------------------------------------------------------------
```
Be sure not to forget the `/** @{ */` and `/** @} */`, which open and close the group.
> **Note:** These grouping characters must appear on their own lines. If they're on a line with other non-comment characters, Doxygen won't process them correctly.
Alternatively, if you wish to define a few groups in succession, you could use the following:
```c++
//-----------------------------------------------------------------------------
/* */
/** \name Group 1 Name */
/** @{ */
//-----------------------------------------------------------------------------
// Insert functions, variables, typedefs, etc., here, along with their
// documentation.
//-----------------------------------------------------------------------------
/** @} */
/** \name Group 2 Name */
/** @{ */
//-----------------------------------------------------------------------------
// Insert more stuff here, along with its documentation.
//-----------------------------------------------------------------------------
/** @} */
/* end of Group 2 Name */
/* */
//-----------------------------------------------------------------------------
```
### Documenting the Group Itself
If you like, you can include documentation that pertains to all members of a group. To do so, use something along the lines of:
```c++
//-------------------------------------------------------------------------------
/**
* \name Group Name
* @{
*
* This is a detailed description that pertains to all the members of this
* group.
*
* \param[in] x - This is an input that pertains to every member of the group.
*
* \returns This is something every member of the group returns, at least in
* some general sense.
*/
//-------------------------------------------------------------------------------
// Insert the members of the group, along with any corresponding documentation.
// You can either document just the first member (see below) or document each
// member separately.
//-----------------------------------------------------------------------------
/** @} */
/* end of Group Name */
/* */
//-----------------------------------------------------------------------------
```
This documentation will appear between the group name and its members in the brief description section of the automatically generated HTML page, but it will not appear with the detailed documentation of any of the members.
### Only Documenting the First Member
If `DISTRIBUTE_GROUP_DOC=YES` in your Doxygen configuration, the documentation on the first member of a group will get spread across all members of the group in the generated HTML. This can be useful, for instance, if you have a handful of functions that all do more or less the same thing—you can document them once in the code, but someone using the Doxygen as a reference manual will be able to see that documentation regardless of which function in the group they happen to be looking at.
For instance, if you have
```c++
//-----------------------------------------------------------------------------
/* */
/** \name Random Generators */
/** @{ */
//-----------------------------------------------------------------------------
/**
* \brief Get a random variable.
*
* Generate a random `int`/`double`/`char`/`string`.
*/
int rand();
double rand();
char rand();
std::string rand();
//-----------------------------------------------------------------------------
/** @} */
/* end of Random Generators */
/* */
//-----------------------------------------------------------------------------
```
the generated HTML will be such that it'll look like you copied and pasted the comment before `int rand()` in front of the other three routines.
> **Note:** If you do not wish all members of a group to share the same documentation, *each and every member must be documented separately*.
# Documenting a Namespace
Namespaces appear throughout our code, but if documentation were to show up before each occurrence of a namespace, those various bits of documentation will get bundled together by Doxygen in a manner depending on in what order it processes the files. To avoid the potential confusion there, namespaces should be documented in `Trilinos/packages/packageName/src/Namespaces.hpp` (or if your package contains subpackages, you could have a `Trilinos/packages/packageName/subpackageName/src/Namespaces.hpp` for each subpackage). Each namespace should be preceded by a comment block along these lines:
```c++
/**
* \brief A brief description of the namespace goes here. The brief
* description is terminated by a blank line.
*
* The detailed description of the namespace follows the blank line. This
* should give an unfamiliar developer enough information to understand the
* purpose of the namespace, what it contains, why it was organized in such a
* way, etc.
*
* If the detailed description continues over multiple paragraphs, separate
* paragraphs with a blank line.
*/
namespace something
{
} // end of namespace something
```
Nothing need to be in the namespace in `Namespaces.hpp`, other than any nested namespaces and their associated documentation.
# General Doxygen Guidelines
The [Doxygen manual](http://www.stack.nl/~dimitri/doxygen/manual/index.html) will tell you everything you need to know about using Doxygen to document your code. Here are some highlights:
## Todos
If, for whatever reason, you are unable to complete the documentation of a class, function, variable, etc.—perhaps you need to consult with a coworker to ensure you have an accurate description of what you're documenting—be sure to use the `\todo` command to flag this as documentation that still needs work. For instance,
```c++
/**
* \brief This function does something really cool.
*
* But I'm not entirely sure what it is yet.
*
* \todo Finish documenting this function.
*/
returnType
awesomeFunction();
```
If `GENERATE_TODOLIST=YES` in your Doxygen configuration, `\todo` items populate the "Todo List" page under the "Related Pages" tab of your package's Doxygen site, so it's easy to see what still needs work.
## Undocumented Entities
When you run Doxygen, for instance,
```bash
cd path/to/Trilinos/packages/packageName/docs
./builddocs.sh |& tee doxygen.log
```
it will warn you about any undocumented entities. You can search through the output for warnings associated with files you've touched to ensure you haven't missed documenting anything. For instance,
```bash
grep warning doxygen.log | grep FileIModified.hpp
```
## Comment Blocks
Note that in the midst of Doxygen-style comment blocks
```c++
/**
* Text
* goes
* here.
*/
```
any leading `*` marks are stripped out by Doxygen before any other processing is done.
## Automatic Link Generation
Doxygen will [automatically generate hyperlinks](http://www.stack.nl/~dimitri/doxygen/manual/autolink.html) in a handful of scenarios. When mentioning a function, be sure to include `()` at the end to tell Doxygen to generate a link to that function's documentation, as in
```c++
/**
* Check out `functionName()`. It's pretty great.
*/
```
## Markdown Syntax
Doxygen does have support for rendering [Markdown syntax](http://www.stack.nl/~dimitri/doxygen/manual/markdown.html).
When it comes to documenting classes, functions, and data as specified above, be sure to use `` `backticks` `` around class names, function names, and snippets of code that appear inline to have them rendered in a monospaced font.
If creating a bulleted list, use non-asterisk bullet markers, as leading asterisks will be stripped away. That is, prefer this
```c++
/**
* Here's a list:
* - Item 1
* - Item 2
*/
```
to this
```c++
/**
* Here's a list:
* * Item 1
* * Item 2
*/
```
## Including Math
Doxygen allows you to include mathematical formulas and the like by surrounding LaTeX with certain delimiters:
* `\f$` for inline math, as in `\f$ E = m c^2 \f$`;
* `\f[` and `\f]` for unnumbered displayed equations, analogous to `\begin{equation*}` and `\end{equation*}`; and
* `\f{environment}{` and `\f}` for other LaTeX math environments, such as `eqnarray`.
See [this documentation](http://www.stack.nl/~dimitri/doxygen/manual/formulas.html) for examples.
## Including Code
There are a handful of different ways to include code blocks in Doxygen, but the one that seems to work in the widest variety of cases is the following:
```c++
/**
* Here's a bit of code
* \code{.cpp}
int
main(
int argc,
char* argv[])
{
std::cout << "Hello World!" << std::endl;
} // end of main()
\endcode
* that prints "Hello World!".
*/
```
The argument to the `\code{}` command is a file extension that'll tell Doxygen what kind of syntax highlighting it should use. Unfortunately, between the `\code{}` and `\endcode` keywords, there is no stripping of leading asterisks as would normally take place. It will, however, strip out whatever leading indentation exists.
# Trilinos' Policy
At a bare minimum, Trilinos requires that any new entities you add have a `\brief` description, and functions additionally require at least the `\param`s and `\returns` information. It is the responsibility of the developer adding the new code to include the relevant documentation. It is the responsibility of the pull request reviewer to not allow a request to be merged until this minimum documentation is in place.
It is also highly recommended that any time you come across undocumented entities, that you either add the documentation yourself if you are knowledgable enough to do so, or contact the file author and ask them to add the documentation. Our goal is to have a fully documented code base, and the more proactive every developer is about that, the easier it will be to achieve.
</details>https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2142Add automated Trilinos build for Intel 17 with GCC 4.8.4 backend2018-01-16T01:19:13ZJames WillenbringAdd automated Trilinos build for Intel 17 with GCC 4.8.4 backend*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @fryeguy52
## Description
It seems people are trying to build Trilinos with Intel 17 (see #2128). This story is to track efforts to get an automated Trilinos build set up ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @fryeguy52
## Description
It seems people are trying to build Trilinos with Intel 17 (see #2128). This story is to track efforts to get an automated Trilinos build set up submitting to CDash with the SEMS-provided Intel 17.
## Tasks
* Have SEMS rebuild `sems-intel/17.0.1` against `sems-gcc/4.8.4` (https://software-sandbox.sandia.gov/jira/servicedesk/customer/portal/4/SEMSHELPD-802) (@fryeguy52)
* Set up CTest -S script that can submit to CDash (@bartlettroscoe)
* Set up Jenkins job submitting builds of Trilinos with `sems-intel/17.0.1` against `sems-gcc/4.8.4` to CDash {{Nighty}} track
## Related Issues
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to: #2128,
* Part of
* Composed of
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2102Please consider moving all installed headers into include/Trilinos2017-12-30T21:17:40ZJames WillenbringPlease consider moving all installed headers into include/Trilinos*Created by: yurivict*
```Trilinos``` installs a lot of headers, and it would be reasonable to have a dedicated directory for them, instead of having them add to already large number of headers in ```include/```.*Created by: yurivict*
```Trilinos``` installs a lot of headers, and it would be reasonable to have a dedicated directory for them, instead of having them add to already large number of headers in ```include/```.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2101Looks for the fortran executable when Trilinos_ENABLE_Fortran=OFF2017-12-30T05:02:27ZJames WillenbringLooks for the fortran executable when Trilinos_ENABLE_Fortran=OFF*Created by: yurivict*
Building with these arguments:
```
-DTrilinos_ENABLE_Fortran:BOOL=OFF \
-DTrilinos_ENABLE_ALL_PACKAGES=ON \
-DTPL_ENABLE_BLAS=OFF \
-DTPL_ENABLE_Netcdf=ON \
-DX11_LIBRARY_DIRS:STRING=${LOCALBASE}/lib \
-DBU...*Created by: yurivict*
Building with these arguments:
```
-DTrilinos_ENABLE_Fortran:BOOL=OFF \
-DTrilinos_ENABLE_ALL_PACKAGES=ON \
-DTPL_ENABLE_BLAS=OFF \
-DTPL_ENABLE_Netcdf=ON \
-DX11_LIBRARY_DIRS:STRING=${LOCALBASE}/lib \
-DBUILD_SHARED_LIBS:BOOL=ON
```
It fails in the end:
```
Set up for creating a distribution ...
Finished configuring Trilinos!
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_Fortran_LINK_EXECUTABLE
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_Fortran_LINK_EXECUTABLE
```
If fortran is disabled, it should disable all packages that require the fortran executable, it shouldn't fail like this. Also, removing ```X11_LIBRARY_DIRS=${LOCALBASE}/lib``` removes this error too.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2103Building with fortran fails on FreeBSD2017-12-30T05:49:12ZJames WillenbringBuilding with fortran fails on FreeBSD*Created by: yurivict*
```Trilinos_ENABLE_Fortran:BOOL=ON``` triggers this error:
```
-- Warning, cannot automatically determine Fortran mangling.
CMake Error at /usr/local/share/cmake/Modules/FortranCInterface.cmake:383 (message):...*Created by: yurivict*
```Trilinos_ENABLE_Fortran:BOOL=ON``` triggers this error:
```
-- Warning, cannot automatically determine Fortran mangling.
CMake Error at /usr/local/share/cmake/Modules/FortranCInterface.cmake:383 (message):
The Fortran compiler:
/usr/local/bin/gfortran6
and the CXX compiler:
/usr/bin/c++
failed to compile a simple test project using both languages. The output
was:
Change Dir: /usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX
Run Build Command:"/usr/local/bin/gmake" "VerifyFortranC"
gmake[2]: Entering directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/local/bin/cmake -H/usr/local/share/cmake/Modules/FortranCInterface/Verify -B/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/gmake -f CMakeFiles/Makefile2 VerifyFortranC
gmake[3]: Entering directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/local/bin/cmake -H/usr/local/share/cmake/Modules/FortranCInterface/Verify -B/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start /usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles 6
/usr/local/bin/gmake -f CMakeFiles/Makefile2 CMakeFiles/VerifyFortranC.dir/all
gmake[4]: Entering directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/local/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/depend
gmake[5]: Entering directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
cd /usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/local/share/cmake/Modules/FortranCInterface/Verify /usr/local/share/cmake/Modules/FortranCInterface/Verify /usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX /usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX /usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortran.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortran
gmake[5]: Leaving directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/local/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/requires
gmake[5]: Entering directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
gmake[5]: Nothing to be done for 'CMakeFiles/VerifyFortran.dir/requires'.
gmake[5]: Leaving directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/local/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/build
gmake[5]: Entering directory '/usr/ports/science/Trilinos/work/.build/CMakeFiles/FortranCInterface/VerifyCXX'
[100%] Linking CXX executable VerifyFortranC
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -pipe -fno-omit-frame-pointer -fstack-protector -fno-strict-aliasing -fno-omit-frame-pointer -O2 -pipe -fno-omit-frame-pointer -fstack-protector -fno-strict-aliasing -fno-omit-frame-pointer CMakeFiles/VerifyFortranC.dir/main.c.o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o CMakeFiles/VerifyFortranC.dir/VerifyCXX.cxx.o -o VerifyFortranC -L/usr/local/bin -L/usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd11.1/6.4.0 libVerifyFortran.a -lgfortran -lssp_nonshared -lquadmath
/usr/bin/ld: cannot find -lgfortran
```
libgfortran.so is in ```/usr/local/lib/gcc6```.
Adding ```-DFortran_LIBRARY_DIRS:STRING=${LOCALBASE}/lib/gcc6``` doesn't help.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2106config files unnecessarily contain references to TrilinosSSConfig.cmake2018-01-03T16:06:42ZJames Willenbringconfig files unnecessarily contain references to TrilinosSSConfig.cmake*Created by: nschloe*
When installing Trilinos, one finds that several package config files, e.g.,
```
/usr/lib/*/cmake/ML/MLConfig.cmake
```
contain the line
```
INCLUDE("${CMAKE_CURRENT_LIST_DIR}/../TrilinosSS/TrilinosSSConfig.c...*Created by: nschloe*
When installing Trilinos, one finds that several package config files, e.g.,
```
/usr/lib/*/cmake/ML/MLConfig.cmake
```
contain the line
```
INCLUDE("${CMAKE_CURRENT_LIST_DIR}/../TrilinosSS/TrilinosSSConfig.cmake")
```
even though the packages themselves do _not_ directly depend on TrilinosSS. This leads to configuration failures on Debian since TriliinosSS is installed only if it is a dependency.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2097Installs stray executable: bin/sphgen2017-12-30T19:45:21ZJames WillenbringInstalls stray executable: bin/sphgen*Created by: yurivict*
It looks like something that is used to generate documentation.
Please, review the list of files installed into ```bin/``` and make sure they are all really needed:
```
bin/aprepro
bin/cth_pressure_map
bin/...*Created by: yurivict*
It looks like something that is used to generate documentation.
Please, review the list of files installed into ```bin/``` and make sure they are all really needed:
```
bin/aprepro
bin/cth_pressure_map
bin/exomatlab
bin/io_info
bin/io_shell
bin/shell_to_hex
bin/skinner
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2096Installs headers conflicting with mpich22017-12-30T04:53:09ZJames WillenbringInstalls headers conflicting with mpich2*Created by: yurivict*
```
===> Registering installation for Trilinos-12.12.1
Installing Trilinos-12.12.1...
pkg-static: Trilinos-12.12.1 conflicts with mpich2-1.5_8,5 (installs files into the same place). Problematic file: /usr/l...*Created by: yurivict*
```
===> Registering installation for Trilinos-12.12.1
Installing Trilinos-12.12.1...
pkg-static: Trilinos-12.12.1 conflicts with mpich2-1.5_8,5 (installs files into the same place). Problematic file: /usr/local/include/mpi.h
*** Error code 70
```
These files:
```
include/mpi.h
include/mpi_config.h
include/mpi_implementation.h
include/mpi_profile.h
include/mpi_prototypes.h
```
are problematic.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2068Dashboard ride CUDA build fails in config; can't find BLAS2017-12-09T20:57:02ZJames WillenbringDashboard ride CUDA build fails in config; can't find BLAS*Created by: mhoemmen*
The Dashboard CUDA build for ride does not pass the configure process, because it fails to find the BLAS:
https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3264127
@trilinos/framework
## Expecta...*Created by: mhoemmen*
The Dashboard CUDA build for ride does not pass the configure process, because it fails to find the BLAS:
https://testing.sandia.gov/cdash/viewConfigure.php?buildid=3264127
@trilinos/framework
## Expectations
Working ride Dashboard build.
## Current Behavior
The ride build doesn't get through the configure process, because it can't find the BLAS.
## Motivation and Context
Applications use Trilinos on ride with CUDA, and need to see a working Dashboard build.
## Possible Solution
Talk to @micahahoward et al. to see how they build on ride. Match their CMake configuration.
## Steps to Reproduce
1. Gaze upon the Dashboard
2. Behold, the ride build reports an error at configure time
## Related Issues
* Related to #1753, #1699, #1675, #1574, #1216
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2065Add sems-scotch/6.0.3/nopthread_64bit_parallel TPL to automated PR builds of ...2018-05-11T19:25:45ZJames WillenbringAdd sems-scotch/6.0.3/nopthread_64bit_parallel TPL to automated PR builds of Trilinos*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/zoltan, @trilinos/zoltan2, @trilinos/shylu
## Motivation and Context
It would be advantageous to add testing of Trilinos with the Scotch TPL to the automated PR ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/zoltan, @trilinos/zoltan2, @trilinos/shylu
## Motivation and Context
It would be advantageous to add testing of Trilinos with the Scotch TPL to the automated PR testing builds (and perhaps other builds) that the Trilinos Framework team runs. Scotch is an important TPL used by several customers and developers. It is directly used in the Trilinos packages Zoltan, Zoltan2, and ShyLU as shown by:
```
$ find . -name Dependencies.cmake -exec grep -nHi scotch {} \;
...
./packages/zoltan2/cmake/Dependencies.cmake:6:SET(LIB_OPTIONAL_DEP_TPLS METIS PaToH ParMETIS PuLP Scotch AMD CCOLAMD OVIS TopoManager rcalib)
./packages/zoltan2/cmake/Dependencies.cmake:8:SET(TEST_OPTIONAL_DEP_TPLS METIS PaToH ParMETIS PuLP Scotch AMD CCOLAMD OVIS TopoManager rcalib)
./packages/shylu/shylu_node/basker/cmake/Dependencies.cmake:5:SET(LIB_REQUIRED_DEP_TPLS Scotch)
./packages/shylu/shylu_node/basker/cmake/Dependencies.cmake:7:SET(TEST_REQUIRED_DEP_TPLS Scotch)
./packages/shylu/shylu_node/tacho/cmake/Dependencies.cmake:6:SET(LIB_OPTIONAL_DEP_TPLS METIS Scotch Cholmod HWLOC HYPRE MKL LAPACK BLAS Pthread QTHREAD VTune)
./packages/zoltan/cmake/Dependencies.cmake:6:SET(LIB_OPTIONAL_DEP_TPLS MPI METIS ParMETIS PaToH Scotch Zlib CCOLAMD OVIS)
```
Story #2051 demonstrated that the BASIC tests in the PT packages in Trilinos pass using the SEMS-provided TPL module `sems-scotch/6.0.3/nopthread_64bit_parallel`. In fact, the CI Build linked to from:
* https://github.com/trilinos/Trilinos/wiki/Policies--%7C-Testing#post_push_ci_testing
now enables that Scotch TPL. Since the automated PR builds of Trilinos do not enable Scotch, branches that pass the automated PR testing may break that other TPL build which enables Scotch. Therefore, to help protect that CI build and Trilinos developers and customers that rely on Scotch in Trilinos, it would be good to add Scotch to the list of enabled TPLs in the automated PR builds (and perhaps in other builds as well using the SEMS env).
## Definition of Done
* [ ] At least one of the automated PR builds of Trilinos enables the sems-scotch/6.0.3/nopthread_64bit_parallel TPL.
## Related Issues
* Blocks
* Is blocked by
* Follows
* Precedes
* Related to: #2051, #1400
* Part of
* Composed of
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2044Look into adding pull request testing to STK/SEACAS integration2017-12-04T18:14:28ZJames WillenbringLook into adding pull request testing to STK/SEACAS integration*Created by: bmpersc*
@trilinos/framework
## Expectations
Instead of directly pushing to the develop branch after local tests pass have the integration issue a pull request so that the PR testing will be done as well.
## Current...*Created by: bmpersc*
@trilinos/framework
## Expectations
Instead of directly pushing to the develop branch after local tests pass have the integration issue a pull request so that the PR testing will be done as well.
## Current Behavior
The integration currently runs a set of tests and if those tests pass pushes to the develop branch directly. This was the pattern all developers used when this tool was created.
## Motivation and Context
With the impending switch to use PR's for all contributions the automated things should also switch to this. Worst case is that is really is unneeded, best case is that it provides additional testing and protections.
## Possible Solution
The tools we are using already know how to push to a github repo, we need to switch that to use a fork, either from someone on the framework team or create one special for this. From there we then need to have an automated way to issue the pull request from the existing tool. Using the github api it may already be possible to issue a pull request from a script. If so this should be pretty easy to do. I will need to look into what is possible with the github api for this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2029No Trilinos checkin emails2017-12-05T02:19:15ZJames WillenbringNo Trilinos checkin emails*Created by: jhux2*
I haven't received any Trilinos checkin emails since November 22nd.
<!--- Provide a general summary of the issue in the Title above. -->
<!---
Note that anything between these delimiters is a comment that will...*Created by: jhux2*
I haven't received any Trilinos checkin emails since November 22nd.
<!--- Provide a general summary of the issue in the Title above. -->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
@trilinos/framework
@bmpersc https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1934Announcement of develop-to-master promotions?2017-11-27T00:48:50ZJames WillenbringAnnouncement of develop-to-master promotions?*Created by: mhoemmen*
@trilinos/framework How does Trilinos announce develop-to-master promotions?
I'm asking because a colleague who works on an app said that they find this out by pulling master by hand, and seeing if new commits ...*Created by: mhoemmen*
@trilinos/framework How does Trilinos announce develop-to-master promotions?
I'm asking because a colleague who works on an app said that they find this out by pulling master by hand, and seeing if new commits arrived. Is that the recommended procedure? Given that #1154 is still open, users won't normally expect nightly updates of master. Thus, it might be helpful to have some kind of announcement on each promotion, like an e-mail to trilinos-users or a post on the website. Kokkos posts an issue for each develop-to-master promotion, then closes the issue when it's done.