lhcbstacks issueshttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues2024-03-19T11:29:19+01:00https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/21Add a way of querying the dependency versions2024-03-19T11:29:19+01:00Chris BurrAdd a way of querying the dependency versionsFor https://gitlab.cern.ch/lhcb-simulation/lbmcsubmit/-/merge_requests/115 though it'll have other uses (e.g. https://github.com/root-project/root/issues/14793#issuecomment-1999462389).For https://gitlab.cern.ch/lhcb-simulation/lbmcsubmit/-/merge_requests/115 though it'll have other uses (e.g. https://github.com/root-project/root/issues/14793#issuecomment-1999462389).Ben CouturierBen Couturierhttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/20Doxygen search not working since the switch to the new EOSWEB servers2023-11-14T11:00:43+01:00Marco Clemencicmarco.clemencic@cern.chDoxygen search not working since the switch to the new EOSWEB serversThe update of PHP implied by the switch to the new EOSWEB servers hits an issue in the version of Doxygen we use (1.9.1) that was fixed in 1.9.7: https://github.com/doxygen/doxygen/commit/9ab5f4f8780c3e0a89eda8a3e34532dff8ed5fe9.
The sp...The update of PHP implied by the switch to the new EOSWEB servers hits an issue in the version of Doxygen we use (1.9.1) that was fixed in 1.9.7: https://github.com/doxygen/doxygen/commit/9ab5f4f8780c3e0a89eda8a3e34532dff8ed5fe9.
The specific fix to the file `search_functions.php` works (tested with https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/davinci/v46r7/search.php?query=DecayTree) and can be applied to all other versions, but for the future it would be wise to update the vesion of Doxygen we use.
Thanks to @avenkate for reporting it.
Tasks:
- [ ] hot-fix all copies of `search_functions.php` in `/eos/project/l/lhcbwebsites/www/doxygen`
- [ ] update the version of Doxygen used to build the documentation pageshttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/19Add checks to CI2023-10-06T23:17:47+02:00Rosen MatevAdd checks to CI- [ ] check that the name corresponds to the path of the file- [ ] check that the name corresponds to the path of the filehttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/18DPA stack with lumi2023-09-11T15:39:00+02:00Patrick KoppenburgDPA stack with lumi@rmatev I'd like a stack with https://gitlab.cern.ch/lhcb/DaVinci/-/merge_requests/937 and https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4270. Should I
1. Build on top of !176 but add https://gitlab.cern.ch/lhcb/LHCb/-/merge_request...@rmatev I'd like a stack with https://gitlab.cern.ch/lhcb/DaVinci/-/merge_requests/937 and https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4270. Should I
1. Build on top of !176 but add https://gitlab.cern.ch/lhcb/LHCb/-/merge_requests/4270 in DaVinci, or
2. Make a new full stack ?
3. Wait for RTA to make one?Patrick KoppenburgPatrick Koppenburghttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/14Naming stack files as .yaml leads to strange behaviour2023-08-04T18:43:29+02:00Rosen MatevNaming stack files as .yaml leads to strange behaviour!172 had the stack description file name end with `.yaml` and not `.yml` as for all other stacks. This lead to nonsense stacks (8) being created (the descriptions and platforms made very little sense). We need some kind of protection for...!172 had the stack description file name end with `.yaml` and not `.yml` as for all other stacks. This lead to nonsense stacks (8) being created (the descriptions and platforms made very little sense). We need some kind of protection for this mistake as it is easy to make and not obvious to spot based on the consequences.https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/12Location of new Doxygen documentation, etc.2023-08-01T12:49:03+02:00Eduardo RodriguesLocation of new Doxygen documentation, etc.I'm very surprised, I must confess, to read that the new Doxygen documentation is being put under URLs such as https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/stacks/RTA/2023.07.04/index.html, see the comment https://gitlab.cern.ch/lhcb-co...I'm very surprised, I must confess, to read that the new Doxygen documentation is being put under URLs such as https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/stacks/RTA/2023.07.04/index.html, see the comment https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/166#note_6930645 in MR https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/166.
I don't think this is viable at all. Let me make several comments and questions, cc @clemenci, @rmatev, @cmarinbe, @decianm, @nskidmor, @pkoppenb:
1) How can analysts and colleagues in general find out such magic URLs, especially that even the "root URL" https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/ returns a 403 - Forbidden hence nothing that hints at how to get a list of available sets of docs.
2) Speaking of the list, where is the list being produced for all new stacks so that people can find what they need? In the old times you would go, say, to https://lhcbdoc.web.cern.ch/lhcbdoc/rec/releases. This is being updated but not https://lhcbdoc.web.cern.ch/lhcbdoc/moore/releases/, for example, see my next point. In any case, the links under https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/stacks/RTA/2023.07.04/index.html do not tell you or point you to the relevant tag under https://lhcbdoc.web.cern.ch/lhcbdoc/rec/releases and others.
3) I checked for the sake of argument the Moore link and https://lhcb-doxygen.web.cern.ch/lhcb-doxygen/stacks/RTA/2023.07.04/index.html and am taken to https://gitlab.cern.ch/lhcb/Moore/-/tree/v54r12?ref_type=tags, which gives the repository at the branch corresponding to the tag rather than the expected documentation for the tag.
4) If the CalVer tags + project label (2023.07.04 and RTA in this instance, respectively) now get explicit in the URLs, how will people be able to know what to look for? We have for example RTA and DPA stack releases, sometimes DaVinci being part of an RTA stack, sometimes not, etc. This is going to get messy and cryptic IMO.
I know it was a lot of work to get Doxygen up and running again, and we should be really grateful - I certainly am. I just want to point out that there are some rough edges, either known or not quite appreciated.https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/11Follow-up from "Generate doxygen documentation"2023-07-18T13:37:07+02:00Marco Clemencicmarco.clemencic@cern.chFollow-up from "Generate doxygen documentation"The following discussions from !165 should be addressed:
- [ ] @pinogga started a [discussion](https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/165#note_6873141):
> Found in this repo: https://gitlab.cern.ch/pinogga/lb...The following discussions from !165 should be addressed:
- [ ] @pinogga started a [discussion](https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/165#note_6873141):
> Found in this repo: https://gitlab.cern.ch/pinogga/lbconfiguration
> The contents of the LbConfiguration directory can be moved to lhcbstacks if desired
- [ ] @pinogga started a [discussion](https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/165#note_6873146):
> Found in this repo: https://gitlab.cern.ch/pinogga/lbutils_doxy
> The contents of the LbRelease directory can be moved to lhcbstacks if desired
>
>
>
> `getString` function from LbRelease is used in `LHCbDoc.py` to write some important files. It relies on the LbConfiguration package. This is the only reason we are using these dependencies.https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/9Versioning scheme2023-08-14T11:14:58+02:00Rosen MatevVersioning scheme@cattanem @clemenci it was not obvious to come up with a stack version for the patch release in !137. I know stack versions are not used for anything right now but probably we should decide on this before they are.
So far our versionin...@cattanem @clemenci it was not obvious to come up with a stack version for the patch release in !137. I know stack versions are not used for anything right now but probably we should decide on this before they are.
So far our versioning schema seems to be `YYYY.MM[.MINOR]` where MINOR is either an implicit 0 and thus omitted or a number that is incremented. Most stacks (e.g. sim, digi) won't have two releases in the same month, but with RTA/DPA this is pretty much a given (especially now that we've agreed to have regular bi-weekly releases).
The question is how do we extend the scheme with patch versions? Some ways I can think of:
1. `YYYY.MM[.MINOR][_PATCH]` (I went arbitrarily with this for now), so e.g. `2022.12_1` for patch to `2022.12` and `2022.12.1_1` for a patch to `2022.12.1`
2. `YYYY.MM[.MINOR[.PATCH]]`, so `2022.12.0.1` for a patch to `2022.12` and `2022.12.1.1` for a patch to `2022.12.1`
3. `YYYY.MM[.MINOR[_PATCH]]`, so `2022.12.0_1` for a patch to `2022.12` and `2022.12.1_1` for a patch to `2022.12.1`
4. `YYYY.MM.MINOR[.PATCH]`, i.e. always explicitly put a minor version number. This would require updating versions up to now.
5. `YYYY.MM.DD[_PATCH]`, `YYYY.MM[.DD[_PATCH]]` or other variants (which might make sense as we go for (bi)weekly releases).
Maybe this is a point we can discuss at a future PAC (even if for this MR we should choose something)https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/8Routine tag of data packages2023-04-19T11:09:36+02:00Nicole SkidmoreRoutine tag of data packagesThe following discussion from !121 should be addressed:
- [ ] @rmatev started a [discussion](https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/121#note_6375229): (+1 comment)
cc @pkoppenbThe following discussion from !121 should be addressed:
- [ ] @rmatev started a [discussion](https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/121#note_6375229): (+1 comment)
cc @pkoppenbhttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/6Unclear dependency on data packages2023-04-20T17:15:48+02:00Patrick KoppenburgUnclear dependency on data packagesWhen releasing a full new Moore/DaVinci stack it is clear that all projects need a new tag. It is not clear which data packages do. Often this information sits in the brain of some developers. The information in https://gitlab.cern.ch/lh...When releasing a full new Moore/DaVinci stack it is clear that all projects need a new tag. It is not clear which data packages do. Often this information sits in the brain of some developers. The information in https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/tree/master/data/stacks does not expose these dependencies.
Better documentation and workflows will be needed if we need to make quick releases overnight for data taking. @gligorovhttps://gitlab.cern.ch/lhcb-core/lhcbstacks/-/issues/2Can stack definitions be modified?2021-03-16T12:24:28+01:00Rosen MatevCan stack definitions be modified?will it be allowed to modify a stack? Some examples can be:
- fix a wrong project version (spotted in the release build but before deployment)
- change/add a tag (any time, e.g. 2 years after deployment)
- add a platform (any time?)
- a...will it be allowed to modify a stack? Some examples can be:
- fix a wrong project version (spotted in the release build but before deployment)
- change/add a tag (any time, e.g. 2 years after deployment)
- add a platform (any time?)
- add a project (when?)
- change the name (when?)
see also thread at https://gitlab.cern.ch/lhcb-core/lhcbstacks/-/merge_requests/11#note_4295511