Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-03-21T00:24:31Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1156Site name consistency2017-03-21T00:24:31ZJames WillenbringSite name consistency*Created by: jwillenbring*
@trilinos/framework @bartlettroscoe @bmpersc
Kitware is implementing a feature that will help us identify when a test goes missing on the dashboard. To do this, a consistent site name is required. Our mach...*Created by: jwillenbring*
@trilinos/framework @bartlettroscoe @bmpersc
Kitware is implementing a feature that will help us identify when a test goes missing on the dashboard. To do this, a consistent site name is required. Our machines are currently identified on the CDash dashboard by machine name. However, in situations where jobs float (including parameterized builds on the other build farm), jobs can run on different machines, and are currently listed as different sites. Could we perhaps assign a single site to all machines on the build farm, or define a "site" per job run?
Done for this ticket is to better define the issue, determine how to get site consistency, and implement the solution.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1155Implement automated pull request testing for Trilinos2018-08-01T20:51:58ZJames WillenbringImplement automated pull request testing for Trilinos*Created by: jwillenbring*
@trilinos/framework
@allevin is planning to develop a capability that will allow for testing of Trilinos pull request prior to having the changes applied to the develop branch. This story will track that w...*Created by: jwillenbring*
@trilinos/framework
@allevin is planning to develop a capability that will allow for testing of Trilinos pull request prior to having the changes applied to the develop branch. This story will track that work. A rough outline for the work is as follows:
1) Adapt some existing scripts that test the pull requests for another project to be more general and serve the Trilinos case.
2) Deploy on a limited, opt-in basis.
3) Deploy on a full basis for all Trilinos develop branch modifications.Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1154Deploy automated develop to master branch testing2017-10-04T16:37:23ZJames WillenbringDeploy automated develop to master branch testing*Created by: jwillenbring*
@trilinos/framework
@allevin has completed revisions toward a capability that will allow us to automate the testing of the develop branch to determine if it is safe to promote that version of code to the m...*Created by: jwillenbring*
@trilinos/framework
@allevin has completed revisions toward a capability that will allow us to automate the testing of the develop branch to determine if it is safe to promote that version of code to the master branch.
We need to deploy this capability. Here are some proposed tasks for discussion for completion of this story:
1. Fully deploy the capability on Aaron's fork of Trilinos. This will allow us to see the capability in action a couple of times from beginning to end. This should use the complete infrastructure intended for the eventually full deployment, including Jenkins.
2. Test the new capability using the primary Trilinos repository, but temporarily disable the push to master.
3. Fully deploy, including the push to master.
Please comment on this approach.Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1138Update list of Trilinos repositories2017-03-14T16:47:41ZJames WillenbringUpdate list of Trilinos repositories*Created by: jwillenbring*
@bmpersc Could you take a pass at quickly updating this [repo wiki page](https://github.com/trilinos/Trilinos/wiki/Policies-%7C-Trilinos-Repositories).
*Created by: jwillenbring*
@bmpersc Could you take a pass at quickly updating this [repo wiki page](https://github.com/trilinos/Trilinos/wiki/Policies-%7C-Trilinos-Repositories).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1091Set up automated testing with SuperLUDist enabled2017-02-24T16:00:22ZJames WillenbringSet up automated testing with SuperLUDist enabled*Created by: ibaned*
As pointed out in #410, #1083, and #1090, it would be valuable to have automated Trilinos testing that enables the SuperLUDist TPL.
@trilinos/framework *Created by: ibaned*
As pointed out in #410, #1083, and #1090, it would be valuable to have automated Trilinos testing that enables the SuperLUDist TPL.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1047Add topics2017-09-21T21:09:10ZJames WillenbringAdd topics*Created by: aprokop*
Github has a new feature: [topics](https://github.com/blog/2309-introducing-topics) that allows for a better discoverability of projects on Github. Please consider adding it to the repository.
@trilinos/framework *Created by: aprokop*
Github has a new feature: [topics](https://github.com/blog/2309-introducing-topics) that allows for a better discoverability of projects on Github. Please consider adding it to the repository.
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/903Allow github integration tool "reviewable" access to repo2017-02-13T16:18:25ZJames WillenbringAllow github integration tool "reviewable" access to repo*Created by: jhux2*
@bmpersc @jwillenbring
This is a request to make the Trilinos repo accessible by the github integration tool [reviewable](https://reviewable.io/reviews#-). See the message at the bottom of the attached screensho...*Created by: jhux2*
@bmpersc @jwillenbring
This is a request to make the Trilinos repo accessible by the github integration tool [reviewable](https://reviewable.io/reviews#-). See the message at the bottom of the attached screenshot.
![reviewable](https://cloud.githubusercontent.com/assets/12970120/20899488/791a6f7a-badf-11e6-9986-496435fefbda.png)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/901Automated testing with docker containers2016-12-06T21:33:39ZJames WillenbringAutomated testing with docker containers*Created by: tawiesn*
This story is to collect all ideas for setting up a checkin/testing environment based on docker containers. The idea is to develop Trilinos on platforms different than Linux but make sure that all tests run on sele...*Created by: tawiesn*
This story is to collect all ideas for setting up a checkin/testing environment based on docker containers. The idea is to develop Trilinos on platforms different than Linux but make sure that all tests run on selected Linux platforms before checkin the changes to the Trilinos repository.
@jwillenbring @maherou https://gitlab.osti.gov/jmwille/Trilinos/-/issues/891Set up automated Nightly testing for PyTrilinos2018-04-11T15:58:48ZJames WillenbringSet up automated Nightly testing for PyTrilinos*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @wfspotz
**Description:**
Currently PyTrilinos is not under any automated testing that gets posted up to the Trilinos CDash site:
* testing.sandia.gov/cdash/
See the...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @wfspotz
**Description:**
Currently PyTrilinos is not under any automated testing that gets posted up to the Trilinos CDash site:
* testing.sandia.gov/cdash/
See the below email chain.
----
From: Bartlett, Roscoe A
Sent: Tuesday, November 29, 2016 4:10 PM
To: Spotz, William F
Cc: Willenbring, James M; Perschbacher, Brent M
Subject: RE: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Bill,
PyTrilinos was enabled by accident. See:
* https://github.com/trilinos/Trilinos/issues/482#issuecomment-263575023
* https://github.com/trilinos/Trilinos/commit/1b14dadb154a2f49e1097c91a0340d66c39306b6
It is not enabled in the correct PT CI build as shown here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2634468
Some work is going to need to be done before PyTrilinos can be built using the SEMS env and include in any automated testing. For example, currently, PyTrilinos is not tested in any automated Trilinos build uploaded to CDash:
* http://testing.sandia.gov/cdash/index.php?subproject=PyTrilinos&project=Trilinos&date=2016-11-28
Getting things set up to test PyTrilinos is something that you are going to need to take up with the Trilinos Framework team (i.e. Jim and Brent) and the SEMS team.
But at the very minimum, you should set up PyTrilinos testing on one of your machines where you have this working.
-Ross
----
From: Spotz, William F
Sent: Tuesday, November 29, 2016 4:04 PM
To: Bartlett, Roscoe A
Subject: Fwd: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Hi Ross,
So does “Pytrilinos-regression” include both of us?
If not, the configure errors were that
1) No python numpy module was found
2) The SWIG version, 1.3.40, was too old — required is 3.0.0
-Bill
----
From: CDash <trilinos-regression@sandia.gov>
Subject: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Date: November 29, 2016 at 1:13:33 AM MST
To: <pytrilinos-regression@software.sandia.gov>
Reply-To: <noreply@sandia.gov>
A submission to CDash for the project Trilinos has configure errors.
You have been identified as one of the authors who have checked in changes that are part of this submission or you are listed in the default contact list.
Details on the submission can be found at http://testing.sandia.gov/cdash/buildSummary.php?buildid=2633954
Project: Trilinos
SubProject: PyTrilinos
Site: crf450.srn.sandia.gov
Build Name: Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI
Build Time: 2016-11-29T08:13:32 UTC
Type: Continuous
Configure errors: 1
*Configure*
Status: 1 (http://testing.sandia.gov/cdash/viewConfigure.php?buildid=2633954)
Output:
Configuring Trilinos build directory
-- PROJECT_SOURCE_DIR='/ascldap/users/rabartl/Trilinos.base/SEMSCIBuild/Trilinos'
-- PROJECT_BINARY_DIR='/home/rabartl/Trilinos.base/SEMSCIBuild/BUILD'
-- Trilinos_TRIBITS_DIR='/ascldap/users/rabartl/Trilinos.base/SE
-CDash on testing.sandia.gov
_______________________________________________
Pytrilinos-regression mailing list
Pytrilinos-regression@software.sandia.gov
https://software.sandia.gov/mailman/listinfo/pytrilinos-regression
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/821static analysis using PVS2016-11-11T20:51:01ZJames Willenbringstatic analysis using PVS*Created by: davydden*
I did a static code analysis on Trilnos 12.8.1 with gcc 5.4.0 (build by Spack with `-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON`) using [PVS for Linux](http://www.viva64.com/en/b/0441/ ). The results are
```...*Created by: davydden*
I did a static code analysis on Trilnos 12.8.1 with gcc 5.4.0 (build by Spack with `-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=ON`) using [PVS for Linux](http://www.viva64.com/en/b/0441/ ). The results are
```
Total messages: 3907
Filtered messages: 1657
```
There are certainly some false positives, but I am sure that there are also those to be fixed.
[pvs_tasks.txt](https://github.com/trilinos/Trilinos/files/586596/pvs_tasks.txt)
Keep in mind that (from http://www.viva64.com/en/m/0036/)
> It is important to understand that all files to be analyzed should be compiled. If your project actively uses code generation, then this project should be built before analysis, otherwise there may be errors during preprocessing.
Steps to reproduce
```
$ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On <blah-blah-blah>
$ make all -j8
$ pvs-studio-analyzer analyze -l PVS-Studio.lic -o pvs.log -j8
$ plog-converter -a GA:1,2 -t tasklist -o pvs_tasks.txt pvs.log
```
For a trial Linux license see http://www.viva64.com/en/b/0441/ .
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/811Set BUILD_SHARED_LIB to ON by default for Trilinos2016-11-17T15:25:53ZJames WillenbringSet BUILD_SHARED_LIB to ON by default for Trilinos*Created by: ambrad*
**Description:** (written by Ross Bartlett)
By default raw CMake projects don't set `BUILD_SHARED_LIBS` which means it is off and you get static libs. That is bad. In general, static libs take longer to create ...*Created by: ambrad*
**Description:** (written by Ross Bartlett)
By default raw CMake projects don't set `BUILD_SHARED_LIBS` which means it is off and you get static libs. That is bad. In general, static libs take longer to create and link and take up a lot more disk space than for shared libs.
Also, shared libs should be the default as per the agreement for the larger [xSDK standards](https://ideas-productivity.org/resources/xsdk-docs/) that are being developed as part of the IDEAS project (see ["Select option used for indicating whether to build shared libraries (default is shared in XSDK mode")](https://docs.google.com/document/d/18028D6nsuhIrCvJnX6c07r8m_Np4SH-aGXMX4svMs1w/edit#bookmark=id.1n8h8pus6rth)).
Also, note that RPATH issues has been resolved (see TriBITSPub/TriBITS#126) and installed libraries and exectuables run without needing to set any env vars.
Therefore, this Story is to change `BUILD_SHARED_LIB` to `ON` by default for Trilinos.
**Original Description:**
@bartlettroscoe: The file ./cmake/tribits/ci_support/CheckinTest.py generates .config files with example configuration changes commented out. One of them is -DBUILD_SHARED:BOOL=ON. But this should be -DBUILD_SHARED_LIBS:BOOL=ON.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/781Trilinos test programs question2016-11-07T18:51:18ZJames WillenbringTrilinos test programs question*Created by: VictorEijkhout*
All the trilinos packages come with test code. I would like to tell users "copy this directory out of the source tree to your own area, set these environment variables, and then you can build an example code...*Created by: VictorEijkhout*
All the trilinos packages come with test code. I would like to tell users "copy this directory out of the source tree to your own area, set these environment variables, and then you can build an example code".
The trilinos test examples don't seem to be designed along these lines. For instance, the test executables are in the build directory, not in the final install. These build directories are (naturally) not part of the installation that I offer to users. Also, they seem for testing the correctness of the installation, rather than as usage examples for users.
Is my proposed scenario possible? I want to offer users kind of a template of how to build a trilinos application.
Victor.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/546Make Trilinos' use of ETI consistent2017-06-02T21:07:25ZJames WillenbringMake Trilinos' use of ETI consistent*Created by: bmpersc*
Trilinos wants to move to ETI to be enabled by default. This requires that all packages use the same ETI system. Currently there are 3, maybe more in Tpetra, Muelu and ifpack2. The goal is to make sure that turning...*Created by: bmpersc*
Trilinos wants to move to ETI to be enabled by default. This requires that all packages use the same ETI system. Currently there are 3, maybe more in Tpetra, Muelu and ifpack2. The goal is to make sure that turning on ETI will not make obscure builds fail due to combining packages that aren't normally during our testing.
Reduce build times for Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/501Develop and use git commit template for Trilinos repo2017-05-15T12:56:09ZJames WillenbringDevelop and use git commit template for Trilinos repo*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
Using a commit template has been shown on other projects to help make commit messages more consistent and contain the proper information.
This story is to cre...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Description:**
Using a commit template has been shown on other projects to help make commit messages more consistent and contain the proper information.
This story is to create a git commit template that will be used by default for all Trilinos commits.
**Definition of Done:**
Git commit template is installed and presented for all Trilinos commits (but the commit author can modify the commit in the editor before the commit is created).
**Tasks:**
1. Learn and document how a git commit template works (see [here](https://github.com/TriBITSPub/TriBITS/issues/138#issuecomment-233959791)) [Done]
2. Develop template for a Trilinos commits (i.e. on a Google Doc) (see [below](https://github.com/trilinos/Trilinos/issues/501#issuecomment-233965160)) ... IN PROGRESS ...
3. Develop automated process for installing git commit hooks (e.g. as a side-effect of running the CMake configure) (see [here](https://github.com/TriBITSPub/TriBITS/issues/138#issuecomment-233962167)) ... Waiting to be worked ...
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/485OpenMP Detection Assumes GNU-Style Preprocessor Directive for Fortran (Incomp...2017-07-13T16:51:19ZJames WillenbringOpenMP Detection Assumes GNU-Style Preprocessor Directive for Fortran (Incompatible with IBM XLF)*Created by: nmhamster*
Trilinos OpenMP detection of flags for Fortran compiler does not work correctly with IBM XLF compiler on POWER8 platform. The detection assumes that the `-D` flag works for passing preprocessor defines through to...*Created by: nmhamster*
Trilinos OpenMP detection of flags for Fortran compiler does not work correctly with IBM XLF compiler on POWER8 platform. The detection assumes that the `-D` flag works for passing preprocessor defines through to the compiler. This is not the case for the IBM `xlf`and `xlf90` compilers where `-WF,-D` needs to be used if we expect the C preprocessor to be called. The correct check should be for `-qsmp=omp` to be found although its not clear this is correctly tested for (possible I have missed it in the error output).
```
/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/bin/xlf -O3 -g -qsmp=omp -qsimd=auto -L/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/lib -L/home/projects/pwr8-rhel72/ibm/xl/xlC/13.1.3/lib -lopen-pal -lxl -lxlopt -lxlf90 -lxlfmath -lm -libmc++ -lstdc++ -L/home/projects/pwr8-rhel72/openmpi/1.10.2/xl/13.1.3/cuda/7.5.7/lib -lmpi -O3 -g -qsmp=omp -qsimd=auto -L/home/projects/pwr8-rhel72/ibm/xl/xlf/15.1.3/lib -L/home/projects/pwr8-rhel72/ibm/xl/xlC/13.1.3/lib -lxlf90 -DOpenMP_FLAG_DETECTED -mp CMakeFiles/cmTC_48a9b.dir/src.F.o -o cmTC_48a9b -Wl,-export-dynamic
```
Yields (incorrect behavior) error of:
```
ld: warning: cannot find entry symbol nMP_FLAG_DETECTED; defaulting to 0000000010000860
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/473Migrate checklists to GitHub Trilinos Developer site2016-06-30T15:13:17ZJames WillenbringMigrate checklists to GitHub Trilinos Developer site*Created by: jwillenbring*
**Next Action Status:**
Updating the new developer checklist ...
**CC:** @trilinos/framework
**Description:**
The process checklists need to be moved from the old developer website to the new Trilinos Dev...*Created by: jwillenbring*
**Next Action Status:**
Updating the new developer checklist ...
**CC:** @trilinos/framework
**Description:**
The process checklists need to be moved from the old developer website to the new Trilinos Developer GitHub wiki.
**Tasks:**
1. Update the new-developer checklist ... IN PROGRESS..
2. ???
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/468Fails to use then supplied openmpi path2016-06-27T20:01:43ZJames WillenbringFails to use then supplied openmpi path*Created by: yurivict*
On FreeBSD OpenMPI headers are in /usr/local/mpi/openmpi/include. During configure and build stages CXXFLAGS has -L flag with this folder.
cmake has these arguments:
```
-DTrilinos_ENABLE_OpenMP:BOOL=ON
-DTPL_EN...*Created by: yurivict*
On FreeBSD OpenMPI headers are in /usr/local/mpi/openmpi/include. During configure and build stages CXXFLAGS has -L flag with this folder.
cmake has these arguments:
```
-DTrilinos_ENABLE_OpenMP:BOOL=ON
-DTPL_ENABLE_MPI:BOOL=ON
-DMPI_BASE_DIR:PATH="/usr/local/mpi/openmpi"
-DMPI_BIN_DIR:PATH="/usr/local/mpi/openmpi/bin"
```
Yet build still breaks with this error:
```
/usr/ports/math/trilinos/work/Trilinos-trilinos-release-12-6-2/packages/zoltan/src/include/zoltan.h:50:17: fatal error: mpi.h: No such file or directory
#include <mpi.h>
```
System calls trace shows that the "openmpi" folder is never looked at for mpi.h.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/453Send out summary email of failing Trilinos Nightly builds and tests at end of...2018-10-11T14:04:09ZJames WillenbringSend out summary email of failing Trilinos Nightly builds and tests at end of each testing day*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Related to:** #380
**Description:**
At a meeting last week between Jim W. (@jwillenbring), Brent P. (@bmpersc), Erik S. and myself (@bartlettroscoe), Erik mentioned that one ...*Created by: bartlettroscoe*
**CC:** @trilinos/framework
**Related to:** #380
**Description:**
At a meeting last week between Jim W. (@jwillenbring), Brent P. (@bmpersc), Erik S. and myself (@bartlettroscoe), Erik mentioned that one of the internal projects had/has a process where they send out a summary email at the end of each testing day that summarizes the failing tests. This email is seen by every developer on the project, the project lead, and the manager. If these tests are allowed to fail day after day, then the project lead (and then the managers) will step in and provide motivation and encouragement for the development team to help address the issues.
With the current CDash setup that is used by Trilinos, a targeted email goes out for every configure, build, or test failure for a package as soon as the results are uploaded and processed by the CDash. This email is targeted to the email list that is attached to a given Trilinos package. This gives that package team a heads up about the failure as soon as it is known. While this is good because it alerts the targeted people as soon as possible, one can't see the fully set of failures at the end of a testing day without going directly to CDash and looking.
This Story is to implement a process where a single email would be send out at the end of each testing day (e.g. at 1 am after the last testing day ended at 12 pm) to all of the Trilinos developers, project leads, and responsible managers with the full list of failing tests for the Nightly Trilinos builds. As described for the other internal SNL project described above, having this feature would help to elevate the importance of keeping the Nightly builds clean and therefore would support beefing up the testing to promote from the 'develop' branch to the 'master' branch.
There are several ways to implement this:
1) Add this as an official feature to CDash and pay Kitware to add it.
2) Implement this as a python script that reads from CDash using the new CDash API.
In my opinion, it would be pretty easy to implement option-2 above given the new CDash API that returns a JSON file for any CDash PHP page. This would be very similar to the script `send_kanban_wip_reminder_emails.py` which I (Ross) wrote for CASL PHI that queries the Trac DB and then creates a customized HTML-formatted email with a nice formatted table. My guess is that writing a script like this could be done in about 4 hours, including some unit tests to define and protect this functionality. You would then set up a cron job to run this script at the same time at the end of each testing day.
Improve productivity, stability, and quality of Trilinoshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/452Decide on how to handle multi-repos with Trilinos both short-term and long-term2016-08-29T16:42:49ZJames WillenbringDecide on how to handle multi-repos with Trilinos both short-term and long-term*Created by: bartlettroscoe*
**Next Action Status:**
???
**CC:** @trilinos/framework
**Blocking:** #440, #176
**Description:**
When Trilinos was trimmed down and moved to GitHub, several extra repos were split out into their own r...*Created by: bartlettroscoe*
**Next Action Status:**
???
**CC:** @trilinos/framework
**Blocking:** #440, #176
**Description:**
When Trilinos was trimmed down and moved to GitHub, several extra repos were split out into their own repos like MOOCHO, Sundance, CTrilinos, ForTrilinos, Mesquite, etc. There was a plan for managing these extra repos using the support for extra repos added for TriBITS to support CASL VERA development in the Goolge Doc [Proposal for trimming down Trilinos repo](https://docs.google.com/document/d/1hbki9KN4ErCChWcvAFBnOsJcPLuDJtPi8xaNq3ETyRo/edit?usp=drive_web) which was started in late 2014 or so. Given that Trilinos was split up, I (@bartlettroscoe) assumed that the plan listed in that document was a reasonable approach to get these extra repos for inserted packages back into automated testing and for distribution in Trilinos releases (because CASL VERA has been doing this for years). Based on this assumption, I created the issue #176 to get this working for Trilinos, CCing the other Trilinos Framework team members. I think did some work on this approach and got many of these inserted packages back under automated testing and added full support for the usage of the TriBITS `clone_extra_repos.py` and `gitdist` scripts. However, my assumption that there was agreement to use the the TriBITS approached used by CASL VERA as an initial way to address multiple repositories in Trilinos was not founded. It seems that others did not agree with that decision.
Therefore, this Trilinos GitHub ticket is to drive and document the discussion of this topic and the decisions on how Triilnos should deal with multiple repos, both short-term and long-term.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/440Switch to 'develop'/'master' branch in all repos listed in ExtraRepositoriesL...2018-08-15T01:35:32ZJames WillenbringSwitch to 'develop'/'master' branch in all repos listed in ExtraRepositoriesList.cmake*Created by: bartlettroscoe*
## Next Action Status:
???
**Blocked By:** #370, #176, #452
## Description:
As described in [this comment](https://github.com/trilinos/Trilinos/issues/370#issuecomment-224391677) in #370, the cu...*Created by: bartlettroscoe*
## Next Action Status:
???
**Blocked By:** #370, #176, #452
## Description:
As described in [this comment](https://github.com/trilinos/Trilinos/issues/370#issuecomment-224391677) in #370, the current implementation of the `TRIBITS_CTEST_DRIVER()` function will clone and use the 'master' branch of the extra repos even if `Trilinos_BRANCH=develop` or `trilinos-release-X-Y-branch`, etc. That is not consistent with treating this set of repos as "one big repo".
Therefore, this story is to switch all of the extra repos listed in Trilinos/cmake/ExtraRepositoriesList.cmake over to the 'develop'/'master' workflow that will be released or used by outside users. Any extra repo that is not going to switch over to the 'develop'/'master' workflow should not be listed in that file and should not be part of automated testing of Trilinos or Trilinos releases. More can be discussed about this but that basics are simple.
## Tasks:
1. Implement TriBITSPub/TriBITS#130 in TriBITS (This will result in `Trilinos_BRANCH=<branch>` getting checked out in each extra repo as well as the base Trilinos repo.) **[DONE]**
2. Determine what extra repos currently listed in ExtraRepositoriesList.cmake should continue being tested and perhaps released and which should not.
3. For those repos listed in ExtraRepositoriesList.cmake (i.e. that will continue to be tested and perhaps released), add a 'develop' branch.
4. Transition to the 'develop'/'master' workflow for all of the extra repos listed in ExtraRepositoriesList.cmake (in one push to the Trilinos 'develop' branch):
a. Update 'develop' branch from 'master' branch in all these extra repos and then lock down 'master' branch like for the main Trilinos git repo in #370.
b. Update the process that updates the Trilinos 'develop' branch to the 'master' branch also update from the 'develop' to the 'master' branches in these extra repos as well.
Improve productivity, stability, and quality of Trilinos