Retrospective notes 2020.02.05
We are happy with how well we have coped with a sprint that threw a lot at us. Thank you everyone for working hard. :)
Cables were tested individually to spot faults but the issue was that both the cables were faulty and weren't tested together earlier on.
It is noted that there were a lot of possible causes for the problem and it was hard to isolate the issue to this.
Solution: A portable laptop with IBEX installed on to test.
- We will have Kathryn's old laptop when set up
- Need to add this laptop to the releases
- Has an IBEX Builder account
- We should add a local admin account
Yes, we should, it is very out of date.
People should be consulted as to who should be added.
The components stewards should all be STFC people at this stage.
This is due to not having or knowing the availability of licenses for squish testing. The licenses are limited to 5 for writing and one for running (used by the builds).
We need to work out who has a license and who should have a license. We should have a floating license so people who need it but not very often, can use it.
Kevin will inquire about options for licensing in terms of having a floating license or changing the names on the license.
A near trivial ticket #4938 (LOQ Eurotherm) took less than 1 day to resolve, but 45 days (elapsed time) to review.
Why?
This ticket was not put in review so people were not aware of it. Sometimes these things slip through, but we should always be careful to follow procedure.
Thank you Dom for checking up on these things to keep it in order.
Are we all using the review column correctly? Should it be prioritized? Should there be an urgent review tag?
The review column is prioritized (the top is the most urgent to review). There is an urgent tag to use that applies to the whole tickets life cycle.
These urgent tickets should be placed higher in the column and we should be working through the column as per procedure documented at https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Tickets-and-their-Workflow
Deployments had to be done late the night before training because the training room was booked up the day before.
We should book out the room for a certain time (probably a day) before the training so we have time to deploy to them.
A positive point was that our deployment took 3 hours between 2 developers for 16 machines, which is fast, well done John and Tom.
An alternative to be would be to have virtual machines with IBEX deployed on that we can remote desktop too. This would be a slower experience and we are not sure about connectivity from ATLAS and R78, but this could even be more realistic.
We have extensive documentation for training at https://github.com/ISISComputingGroup/ibex_developers_manual/wiki/Training-Instrument-Scientists-in-IBEX
We've coped with it well but it would be nice to have something like a Friday to make up for it.
We should think about spreading responsibilities away from Tessella people so as not to silo information for when they leave :(
We need to be able to do things without Tessella people to prepare for them leaving. This includes areas such as support, training and the SANS DLS.
In all areas, STFC people should make a conscious effort to offer their help when possible and Tessella people should make a conscious effort to ask for help.
This is as simple as including a third person in a conversation between to Tessella people.
We could make a label for tickets that it is very important to have STFC people on?
Yes, as noted in component stewards discussion documented above