Starting again to have a Build Manager

Development
#1

Hi devs,

I’d like to propose to have a Build Manager again. The goal would be:

  • We can regularly see functional tests failing for a week or more and we also tend to start looking at failing tests only a few days before a release, thus taking a long time to fix and wait for rebuilds.
  • Fix more flickering tests
  • Improve the PO objects where needed, make sure that tests don’t use getDriver() (that should be only in POs).
  • Convert old func tests to docker-based tests
  • Add missing tests as raised by Ilie with jira issues
  • Review/Analyze/Fix CI environment issues
  • Generally, anything related to the build stability on the CI

The idea would be to have a rolling Build Manager in the same way we have a rolling Release Manager. The reason I’m not proposing the RM to be also the BM is because a RM role lasts for 3 weeks and it’s a long time to be responsible for the build, and the RM already has a lot to do. I think it would be easier to have weekly BM, as we used to have.

I’d propose to use what we defined in the past: Development Practices (Community.DevelopmentPractices) - XWiki (we should probably update a bit the description to match more our current need in order to give more updated examples).

We could also improve Build Manager Roster (Community.BuildManagerRoster) - XWiki by generating the next BM automatically and sending a notification email every week to the new BM.

One important goal of the BM would be that every week, the CI is left in a more stable state than it was before each BM started working on it, so that we progress on the CI, instead of going the other way around.

This means that the BM role would not be a best effort role but an active role with time planned and dedicated to the role for the person responsible for the build.

Specifically, this means a bit less time for the roadmap. For the BM week, I’d propose the BM to work 2 hours per day (which ends up to being 20% of the week, but I think it’s important that the work be every day, to discover problems early for example. Also I think the day should start with these 2 hours as pushing them for later would risk missing them, ofc that should be a guideline only). Globally, since we’re more than 4 devs, this would mean 20% spent on the build officially per release and about 1 to 1.2 days per month per person, which seems reasonable to me.

WDYT? I wonder if 2 hours is enough to progress enough or if it should be 4 hours (1/2 day), opinions?

Thanks

#2

I like the idea so +1 to have this role again, at least for few months and see how it goes.

+1 for having a weekly BM, I’m not so sure about your computation though since you consider that the RM should not have a BM duty during the time he’s RM, so it means less devs available for being BM.

I don’t think 2 hours/day would be a good use of the time for the assignments you suggested (e.g. fixing flickering tests, investigating a CI infra issue, adding or converting a test). IMO those task are generally taking lots of time and it’s best to not switch context for them when possible. I think it would be probably better to have 12h/week to work on this, that could be splitted in 3 half days or twice 2h and a full day etc.

#3

+1 to get back the BM role from the dead

IMO we can’t do this every week without a tool to tell us who is on duty a given week (and ideally the few following ones) so this is a requirement and not a nice to have if we want to do this.

You can’t really do much more than reviewing build problems and notify the right people about it in 2 hours.

#4

I agree, in 2 hours no you can’t, but in 2*5 = 10 hours you can do more IMO.

#5

+1. Now, from the goals you listed I won’t be able to help much with “Review/Analyze/Fix CI environment issues” or with fixing the pipeline (without spending considerable time to learn more about it) but I can handle the rest. My point is that I wouldn’t expect each BM to work on all of those goals. Each BM could work on the areas they are more familiar with, in order, at least for a start, to be efficient.

Thanks,
Marius

#6

(very late) +1

#7

I’ve now updated Development Practices - XWiki a bit.

See Development Practices - XWiki

Remaining work:

  • Create a small app
    • record who’s the BM (xclass with 3 fields, start date, end date, user + LT/LD)
    • scheduler job with groovy script to execute every Friday afternoon (for ex) and send a mail to the notifications mailing list to indicate the new BM for the following week. The script will also create a new page with an XObject in it and update the content of another page listing all the available BMs, by moving the first name of the list to the end.
  • Decide when we start it