#2692: Inclusion of FUKA importer thorns
Reporter: tootle
Status: new
Milestone: ET_2023_05
Version: ET_2023_05
Type: proposal
Priority: major
Component: EinsteinToolkit thorn
Comment (by tootle):
As I said, no issue with excluding this line since THC is not part of the toolkit. I have provided in the documentation details related to what needs to be handled by the EOS manager \(or by a third party thorn such as kadath\_pizza\).
I will look into the hooks you mentioned as I'm not familiar with this.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…
#2692: Inclusion of FUKA importer thorns
Reporter: tootle
Status: new
Milestone: ET_2023_05
Version: ET_2023_05
Type: proposal
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
That still leaves point \(b\). Note that _if_ `kadath_pizza` \(2 typos actually, “F != f” and “katathpizza != kadath\_pizza”\) is included then, to match what is done for the other `DISABLED` thorns \(which can be enabled using simfactory’s `enable-thorn` machine ini option\) then `kadath_pizza` should show up in the `!CHECKOUT` line so that GetComponents checks it out, but Cactus does not use it. See eg ReprimAnd.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…
#2692: Inclusion of FUKA importer thorns
Reporter: tootle
Status: new
Milestone: ET_2023_05
Version: ET_2023_05
Type: proposal
Priority: major
Component: EinsteinToolkit thorn
Comment (by tootle):
@{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} No issue with removal.
As an FYI for those they may be interested, this is simply a typo and the line should read:
`#DISABLED Fuka/kadath_pizza # Only for use with WhiskyTHC + PizzaBase`
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…
#2692: Inclusion of FUKA importer thorns
Reporter: tootle
Status: new
Milestone: ET_2023_05
Version: ET_2023_05
Type: proposal
Priority: major
Component: EinsteinToolkit thorn
Comment (by Roland Haas):
The current thornlist contains:
```
#DISABLED fuka/kadathpizza # Only for use with WhiskyTHC + PizzaBase
```
but
\(a\) [https://bitbucket.org/fukaws/kadathpizza](https://bitbucket.org/fukaws/kada… is private \(I get a 404 error trying to access\)
\(b\) Pizza is not part of the eT
\(c\) capitalization matters, `fuka` and `Fuka` are different arrangements
I would suggest to remove the line from the thornlist \(GetComponents will fail with a failed download\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2692/inclusion-of-fuka…
#2697: Include BBH+scalar field initial data code from Canuda in ET
Reporter: Cheng-Hsin Cheng
Status: new
Milestone:
Version:
Type: enhancement
Priority: major
Component:
Comment (by Roland Haas):
uh, not quite sure I follow. For the ET owned repo’s branch \(I guess manifest is the repo\) branching off of master is preferred. The reason being that “master” is the branch that actually gets tested on the cluster and that people who want the bleeding edge code download.
For branches in Canuda’s home org: your choice really. As long as the master branch of `einsteintoolkit/manifest/einsteintoolkit.th` points to the the proposed branch in Canuda \(after the does no harm\) then this is fine \(eg a couple contributions use “main” instead of “master”\). There is a slight advantage if the proposed branch is the default branch since that is the one GetComponents will chose if not branch name is given \(and the vanilla “development” thornlist has no `REPO_BRANCH` statements\). But that is very minor and really only exploitable if the default branch is the branch development happens on \(and not eg the last stable release one\).
Note for release manager: having `REPO_BRANCH` in the development thornlist will likely require some changes to the scripts \(and script fragments\) used to create the release thornlist \(since it assumes that it can just add `REPO_BRANCH` and does not have to modify existing `REPO_BRANCH` statements\).
The branch name in outside repos is not under control anyway and with GitHub advertising against “master” there is a proliferation anyway \(“main”, “devel”, “development” seem to be popular\).
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…
#2697: Include BBH+scalar field initial data code from Canuda in ET
Reporter: Cheng-Hsin Cheng
Status: new
Milestone:
Version:
Type: enhancement
Priority: major
Component:
Comment (by Samuel Cupp):
That should be ok, but I’d like a maintainer to weigh in. When we make the ET\_2023\_05 branch, we would just have to branch it off of that instead of master. @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} @{557058:1671c5c3-29cc-4e83-9850-a152d33a6235} any issues with this?
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2697/include-bbh-scala…