Reducing bus-factor in Fluidity infrastructure

[tmbgreaves]

Due to various job changes my time available to Fluidity has dropped very significantly of late and is likely to be even lower over the next few months and potentially longer term as well.

I think there are some resources which are currently bottlenecks on bus-factor, in some cases with my account as the only one managing them, and would like to improve this ASAP.

Ones I can immediately think of are:

• The dockerhub Fluidity project ( https://hub.docker.com/orgs/fluidity/ ) which I am the only one in the owner team for
• The fluidity-core launchpad team which I'm the only one to have pushed to in a long time, and I don't know whether any of the other owners still have access to their Launchpad accounts
• The Fluidity longtests worker systems which I think I may be the only active project member to have accounts on

For all the above I'd be extremely grateful for volunteers from the developer community to come forward as maintainers to keep things going if I'm not around. Dockerhub isn't actively used at the moment but has often been a useful resource to have available, and Launchpad is a critical part of the infrastructure to disseminate packages for new Ubuntu releases.

Lastly - are there any other resources anyone can identify where we have low to unit bus factor that needs fixing?

[jhill1]

Hi Tim, I guess my immediate questions are if any of those things are vital to users? Do we still want fluidity to be installed via ubuntu packages or do we drop it down to "Install these packages", then build fluidity via configure; make; make install? I've never used the dockerhub thing, so won't comment there. Happy to contribute to the longtests workers, assuming I don't need an ICL account to kick them when needed (and there's some docs so I know what to do ;-). Cheers, J

…

On 07/12/2021 00:58, Tim Greaves wrote: Due to various job changes my time available to Fluidity has dropped very significantly of late and is likely to be even lower over the next few months and potentially longer term as well. I think there are some resources which are currently bottlenecks on bus-factor, in some cases with my account as the only one managing them, and would like to improve this ASAP. Ones I can immediately think of are: * The dockerhub Fluidity project ( https://hub.docker.com/orgs/fluidity/ <https://hub.docker.com/orgs/fluidity/> ) which I am the only one in the owner team for * The fluidity-core launchpad team which I'm the only one to have pushed to in a long time, and I don't know whether any of the other owners still have access to their Launchpad accounts * The Fluidity longtests worker systems which I think I may be the only active project member to have accounts on For all the above I'd be extremely grateful for volunteers from the developer community to come forward as maintainers to keep things going if I'm not around. Dockerhub isn't actively used at the moment but has often been a useful resource to have available, and Launchpad is a critical part of the infrastructure to disseminate packages for new Ubuntu releases. Lastly - are there any other resources anyone can identify where we have low to unit bus factor that needs fixing? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#341>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDFJKL4AM64ABJICARSMV3UPVL3NANCNFSM5JP773EA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Dr Jon Hill Senior Lecturer in Physical Geography Chair of Dept. Equality and Diversity Committee Chair of Board of Examiners Department of Environment and Geography University of York M: +44(0)7748254812 P: +44(0)1904 324480 Web: https://jonxhill.wordpress.com/ Web: https://envmodellinggroup.github.io/

[stephankramer]

Dockerhub isn't actively used at the moment but has often been a useful resource to have available
I presume it's still essential in the CI build-test cycle, no?
I don't know how dockerhub "organization"s work, is it possible to add me as an owner (my dockerhub id is stephankramer) ? I do also still have a launchpad account (https://launchpad.net/~s-kramer) so you could up me to administrator for fluidity-core I guess?
I think you've done quite a bit of work already in recent years to make things maintainable. So I'm quite happy to keep things as they are for now and willing to step in when needed on the first two items. As Jon mentioned in the future it might be enough for most people to just have instructions to build things for themselves (which does also include building zoltan and having a petsc build with sufficient options switched on), but at the moment we're up to date up (up until impish?) so if it's not too much effort I'm happy to see if we can keep it moving forward provided upcoming ubuntu upgrades are minimal effort, and if not we can see who actually needs it then...

[gnikit]

Another option would be to pass the responsibility of generating releases (and binaries) to GitHub Actions. For example for GCC version X on ubuntu-latest, we build Zoltan, PETSc (and HDF5?), compile Fluidity and then package it to a snap/deb/conda/pypi/fpm. The equivalent of fluidity-dev in that case would be installing only Zoltan, PETSc (and HDF5 and its compilers?)