@anon46505572 Thanks a lot for taking on the Lilac upgrade! 
@adolfo Regarding Maple, what’s the target release date? I think we’d have to start the planning phase of the Maple upgrade epic no later than two months before the release date, but let me know if you think more time would be needed. (CC @demid, in case you have some input here as well as owner of the Koa upgrade epic 
)
maple.master will branch off from master on October 9th, exactly two months before the release date, December 9th. This makes October 9th the perfect date to start the process, because we’ll know what to target. But by “start the process” I mean at the very least having an epic created and a few discoveries in motion.
Maple will be a complicated upgrade, because there will be no support for edx/configuration. Assuming Grove will replace it for us, it will not only have to be working by then (which means coordination with @shimulch on BB-4199), but the Ocim frontend will need to be ported to it as well, and we will need to have a migration plan for everybody. If we guesstimate the work to be in the order of 900 hours (which even though more expensive than any other upgrade, it is still a rather optimistic figure), and that it needs to be done in at most three months, this means that from October 9th to January 9th we’ll need to spend around 300 hours per month.
That is at least 3 developers very nearly dedicated to the work. We need to make sure those numbers are in the spreadsheet.
Thanks @adolfo, that’s useful info to have in mind.
I added 300h for Oct-Dec to the spreadsheet, and that put us way above capacity for Q4. I haven’t done a full planning pass this sprint yet, but something will have to give (unless the new recruitment process allows us to increase the size of the cell much quicker than the current one).
@tikr Upgrade work could be something we give to newcomers? It requires some devops access, but it’s also not rocket science work? This could even be a type of trial project?
As I commented on FAL-2160, we need to catchup on the release upgrade work, or we’ll end up paying for it by having progressively bigger jumps of releases to do at once, and those are painful.
Also, we need to do our part of the work to contribute to the releases, which is included in the release upgrades epics. Do we have an epic and an owner for Maple?
(I’ve moved this part of the thread from the Lilac discussion to a new dedicated one.)
NB: Same remark for other devops maintenance epics like https://tasks.opencraft.com/browse/BB-680 - they could be a good source of trial project and/or newcomers tasks?
Yep, that’s definitely an option and something we’ve done before.
I’m not sure about that. The risk of work not getting completed on time and/or up to standard seems higher in this scenario than when giving upgrade work to newcomers that already completed their trial project successfully. If we use it sparingly, the approach may work, though 
Yes, these types of epics would be a good source of work for newcomers 
We’d just have to find/agree on a way to deal with sustainability implications. (The DevOps epics are usually on non-billable cell accounts, so if newcomers take longer to complete tasks than core team members would – which is not uncommon and understandable – this will impact cell sustainability negatively.)
We have an epic (SE-4957) but no owner yet.
In terms of capacity, Serenity could keep this epic or take the blocking FAL-2081, but not both. (This is after incorporating the capacity updates from Campus.)
Since Bebop has the most context on Grove-related epics at the moment it would make sense to see if we can find a way to move FAL-2081 to Bebop. As far as I’m aware, one potential option would be for @giovannicimolin to take it on (cf. this comment).
We need to give substantial & difficult work as trial projects (cf Recruitment: Trial projects & bounties ), otherwise we won’t be able to judge them. They might (and some will) fumble the work, but that’s the principle – we need to see if they can take it. Upgrade work, by its nature, isn’t urgent to one given sprint, if we plan ahead enough – when some newcomers fail at it, we can reschedule another task to do it again, from scratch if necessary.
A trial project that fails can be logged against the recruitment budget (cf also Recruitment: Trial projects & bounties ) – it will replace the onboarding budget in that case. Trial projects should be safe from a budget perspective (and it’s also meant to be the case for tasks given to newcomers btw - the difference between the time it took for a newcomer to do the task and what it would have taken a confirmed core team member is meant to be moved to the recruitment budget).
Thanks! Can I let you figure out where/who will take this on? Let me know if it ends up blocked.
@antoviaque Sounds good We’ll just have to make sure that this gets done consistently. Something to explicitly include in the monthly account review for sustainability, perhaps.
Yes, I’m working on getting epic ownership for upgrade-related epics (including SE-4957) sorted out.
@jill @farhaan @shimulch @antoviaque Some good news regarding the Maple upgrade: @gabor has agreed to take on FAL-2081 (
), starting from Sprint 259.
We don’t have an owner for the Maple upgrade itself (SE-4957) yet. Since FAL-2081 and SE-4957 will need to be completed sequentially, at least to some extent, it might be possible for Serenity to own both epics after all. However, considering that the effort involved in the Maple upgrade will be larger than other version upgrades that we worked on recently, Serenity will likely need substantial help from the other cells, including their newcomers.
CC @anon46505572 as owner of the Lilac upgrade (FAL-2160)
(): For future reference, FAL-2081 is the second sub-epic of BB-4199 that is currently blocking the Maple upgrade.
Gotcha. Thank you for the heads up here, and for getting FAL-2081 resourced and assigned!
@tikr Thanks for the heads up 
@serenity Another update about the Maple upgrade:
So we can continue the process of finding an assignee for the Maple upgrade epic:
Based on these points it seems like our best options for taking ownership of the Maple upgrade would be @jvdm and @pooja. Would one of you be up for it?
Upgrade work that requires coding, testing, and bug fixing – yes, these are great candidate trial tasks, especially if we flag these issues early in the upgrade epic planning, so we have enough lead time.
But I wouldn’t feel comfortable with using the actual site upgrades as recruitment trials – not because they’re too hard, but because the timing is critical to the client and their users, and we could lose data or damage our client relationships if things go wrong.
@jill Good point that we don’t want a disaster for the actual upgrade on the production servers – but maybe they can do all the preparation work, up to and including a staging server upgrade, and preparing the instructions for a core team member to do the final operation on the production servers, after all the quirks have been ironed out?
to this idea.
@jvdm @pooja Friendly reminder to have a look at the post above about epic ownership for the Maple upgrade 
As a general update:
CC @serenity
I wish this came up for discussion earlier. For the past few sprints, @demid and I have been pushing preparation work for the upgrades whenever someone asked for an extra task, so all the remaining work it to upgrade the current stage/production servers.
Not sure there’s much to evaluate from having newcomers just upgrading servers (there’s a second implication: giving full access to production servers and extra credentials).
I was considering to take it, but I went on vacation and it ended up being assigned while I was off. Thanks for taking it up @gabor, and let me know if you need a reviewer or help with it.
@tikr Where do we stand in terms of assigning the Maple upgrade epic? The release working group has been reiterating their call for testing and contribution to the upcoming release, during the contributors meetup yesterday – are we participating?
@antoviaque We don’t have a confirmed assignee for the Maple upgrade yet. I was going to repeat my earlier ping towards the end of last sprint; but after learning that the LX project cell was going to be created this sprint I decided to hold off and get confirmation on this approach first. (Because I thought that merging the generalist part of Falcon back into Serenity might increase our options for getting the epic assigned.)
Anyhow, based on your update I went ahead and assigned the epic (SE-4957) – even if we need to change the owner again, this will hopefully help speed things up in the short term. Serenity does have a couple newcomers looking for tasks (ref, ref), so it seems like it would be possible to get started on some of the work (*) once a first batch of tasks has been created.
–
(*) One of the blocking tickets from the Lilac upgrade is not completely done yet, so branch prep for Maple may need to wait a bit longer.
Almost all upgrades use a client account. So wouldn’t we be affecting the total number of billable hours if we started using non-cell, internal budget instead?