General developer forum

Do you find the code freeze/on-sync period problematic?

 
 
Dan at desk in Moodle HQ, Perth
Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

I was interested to read Sam Marshall's post, saying:

On the other hand, because of the way Moodle development works there is a huge gap between 2.7 and 2.8 development during which the code will rot and this will make significant extra work...

We've discussed the nature of the code freeze and on-sync periods internally in the Integration team and I've never been convinced that it is a significant problem to change process. In fact, I see the ease of branching and the git tooling for maintaining branches one of the main advantages of moving to git and I don't think a long-lived feature branch is problematic. [1]

To quickly outline the current process, as it will happen for Moodle 2.7:

  1. We will stop accepting changes/new features for 2.7 - call it Week 1
  2. For a month we will do Quality Assurance and polishing on the release
  3. On the day of release of 2.7, we branch for MOODLE_27_STABLE - Week 5
  4. For 3 weeks after the release we keep master and MOODLE_27_STABLE the same (we call this the on-sync period)
  5. Week 8 - New features again start getting integrated to master

Now you might think - this is 2 months where your code is sitting on a feature branch rather than in master, of course thats problematic.. but:

  1. It keeps our resources focused on making the best release possible. That means not having an integrator or tester tied up in reviewing and testing a huge change which is for a future release.
  2. The changes going on in master should only be bug fixes, so the 'bit rot' should be limited. (Though it should be acknowledged that our discipline about code freeze has been less than ideal and is something we are committed to become much tougher on this release).
  3. It reduces the amount of conflict resolution work developers working on the 'current' (say 2.7) release have to do. In fact it moves the problem of conflict resolution to the 2.8 developers.
  4. I think it sets the tone of our focus as a development community. This might not be easily quantifiable, but I think its helpful that everyone is clear what our focus is and why we are not dealing with future changes at the time.

Note there are many other ways we could conduct development... Some examples:

  • We could branch at code freeze (point 1) and immediately start accepting changes for 2.8. I am really unconvinced of this approach, because I know what drain on resources it would be. I think it would diminish from the quality of the release.
  • We could abolish the on-sync period. I'm not especially against this idea, but I don't think those 3 weeks make a huge amount of difference.

What have been your experiences been and what do you think?

[1] I am very comfortable with git though wink

 
Average of ratings:Useful (8)
Picture of Michael Aherne
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers

Very interesting post, Dan! Could you explain what the "on-sync" period is for?

 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Hi Michael,

One of the ideas behind behind the on-sync period is to keep the versions between master and lastest_STABLE (e.g. 27) the same. The period immediately following a release tends to be when we get upgrade problems reported and by keeping the version the same we can ensure that any 'fix' upgrade steps only need to be executed once for people upgrading later.

Joking, I referred to it on chat as the 'integrator mojito period' the other day - but there is a certain element of truth to it being a useful 'rest period'. It is a period of calm following the (controlled) chaos that goes into creating a release. It means testers and developers are spared from testing/developing on another branch.

If you are fixing a critical upgrade bug in a mdl_course database, it will be harder work & slower to get the fix for that if you also need to deal with the commit which landed the day after the release which splits mod_course into 10 tables or something wink

 
Average of ratings:Useful (4)
Martin Langhoff - Sailing
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers

keep the versions between master and lastest_STABLE (e.g. 27) the same

Good point. I hadn't thought about this. I had your comment about "developer focus" in mind, and that git treats all branches the same, and this completely flew past me.

So upgrade.php/versions.php is a strong technical reason to have this longish freeze of master.

If upgrade.php/versions.php turns out to be an irritating problem, I think there is a path forward. When I was running a heavily patched Moodle (~2008) I had a draft plan for adding support for "upgrade.d/.php" -- to be used until the point we're ready to put all the upgrade steps in upgrade.php and the schema files.

 
Average of ratings: -
Me!
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers
Here are 2 different examples I have had this round with big patches in feature branches that have waited a while before being integrated.

1 - Cron rewrite. This conflicted the entire cron file for 6 months, and so every tiny change to cron had to be manually disected and added to the new branch. It felt a bit painful - but was manageable.

2 - Atto. This was a new plugin that didn't conflict with anything (except one tiny bootstrap change) and was no drama rebasing for a few months.

In the past, I have also had big assignment feature branches that required constant rebasing - and in some cases the conflicts were so bad it was easier to write the feature again. I still think this was OK, as the second time I wrote the feature it was easier / clearer and came out better.

Really - if the freeze is working properly - any conflicts should be minor and no problem to resolve. I am not super sold on the on-sync period - but I feel like there is something important about it I am forgetting.

 
Average of ratings: -
Martin Langhoff - Sailing
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers
This caught me by surprise! I thought you guys were still using a similar style as we did on CVS, where 'master' only freezes very briefly. And just on time, as I am planning something important related to this (more on it soon wink ).

TBH, we don't find it problematic. We're ok with this; in general if you're good with git (and we are), there's no problem.

However, if there are lots of feature work happening on branches, then those will be missing integration. Yes, you can rebase it (or merge it) periodically to integrate with the latest in bug fixes, but different feature branches get no integration opportunities. You end up learning that they conflict (in code or in functionality) only once master thaws.

Are there many such branches? If/when we hit that problem, there's a good strategy for it, taken from the git project itself.

They have a branch: pu ("proposed updates"). It's a "throwaway" branch, that gets pushed to the repo, but rewound/re-set frequently. That branch has _all_ the feature and bug fix branches. It's done manually, but it's also possible to automate. If branches collide, people get emailed...
 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Are there many such branches?

In general i'd say no, however we are starting to see this increase in Moodle HQ (which is a useful improvement IMO). The equivalent in this scenario would be all the branches waiting for integration in the tracker with (integration_held) label. There probably would be 30 or so by the time of release - but they don't tend to collide much.

They have a branch: pu ("proposed updates"). It's a "throwaway" branch, that gets pushed to the repo, but rewound/re-set frequently. That branch has all the feature and bug fix branches. It's done manually, but it's also possible to automate. If branches collide, people get emailed...

This is something we would quite like to do for the normal weekly integration as well as freeze-held issues so that conflicts can be resolved in advance of a manual integration. I think it'd need some magic to whitelist some files like lib/db/upgrade.php and version.php though.

 
Average of ratings: -
Martin Langhoff - Sailing
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers

[pu] is something we would quite like to do

if there's a way to query Jira for the appropriate tasks, we could have this mostly automated.

Reading LWN.net today I remembered that the kernel folks do the same -- it's called "linux-next", and has its own mailing list. See https://lwn.net/Articles/291292/

If we do a partial automation, with a human eyeballing the conflicts, and perhaps making an initial try at resolving them, then git rerere can help lots.

whitelist some files like lib/db/upgrade.php

hmmm. Agreed.

In addition to git rerere, there are a couple things we could do to improve lib/db/upgrade.php (and friends) to make them less likely to hit pointless conflicts.

edit: grrr! re-editing a post in markdown format is borked. This was working until recently. My ">" characters get turned into & when I re-edit it.

 
Average of ratings: -
Picture of Justin Filip
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Testers

Thanks for this, Dan.

I don't see a problem with this process. The only problems that really arise are when the freeze is more of a mild chill. This means that anyone who starts to use master to integrate their own work has the ground shifting beneath them and potentially breaking their own work in really significant ways.

Though, you did address this and I know it's been mentioned before that there is going to be more discipline used moving forward. This is a good thing.

Personally, I think the long time that someone is sitting on a feature branch before master unthaws is a good thing. It gives them time to finish things off, resolve any bugs that may have cropped up just before the freeze, or deal with any problems introduce by dependency on a bug that has gone away. =)

Is the on-sync period really just meant to allow one dev sprint of focus on any potential critical bugs that have surfaced after the point-oh release is wild?

 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

This is a good thing.

Thanks Justin, its good that many of you see the real benefits of the freeze. Its good for developers, it's good for documentation writers, it's good for translators, it's good for add-on developers, it's good for a quality release. (And hopefully our users will appreciate it too, even if they miss our on mod_amazingnewmod).

It gives them time to finish things off, resolve any bugs that may have cropped up just before the freeze, or deal with any problems introduce by dependency on a bug that has gone away. =)

Ha, nice theory - not sure it reflects reality!

Is the on-sync period really just meant to allow one dev sprint of focus on any potential critical bugs that have surfaced after the point-oh release is wild?

See my response to Michael above. smile

 
Average of ratings: -
Picture of sam marshall
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

Well, I'd better reply to this smile Sorry for a long reply.

I'll outline what the OU does (simplified) for comparison. Basically we follow a more 'normal' pattern of branching on freeze.

  • At code freeze, a new stable branch is created.
  • We have a four week test period (this is for quarterly releases, by the way). During this period, any changes have to be committed to both master and stable branch.
  • In theory, development can continue on the master branch during the test period. But in practice, all our testing resources are tied up with the release testing, so any new features that require testing won't land on the master branch during the test period.

So in other words, practically there's not much difference - during the test period you can submit features for testing, but nobody will test them, so they'll just get added to a backlog and won't get onto the master branch.

There's a difference in focus though. You (Dan) say the changes after code freeze should only be bugfixes. For the OU system it's the same, but I think we're probably a little more strict - we say they should only be bugfixes discovered in testing the new release (or very shortly before the code freeze). In other words the code freeze isn't just a freeze for new features, it's a freeze for bugfixes too, unless those are bugs introduced by/discovered in testing of the new release. (Not saying we always stick to this, but we do a lot better than we used to.)

Before we had this policy (when it was just 'bugs, no features'), the code freeze acted as a perverse incentive - developers like me all did their feature work and completely saved all our bugfixes to the code-freeze month, because we knew we could get them in later. So there was a massive swarm of bugfixes, some major, that all landed in the supposedly frozen code as fast as developers could code them. Is that happening in Moodle? (I have no idea.)

Having a separate branch is an incentive to encourage the opposite approach. Basically you actually want to make it seem slightly more serious to apply a bugfix during code freeze, and requiring two branches points that out. (It's not really that hard, because git, but it at least makes you think twice.)

To summarise:

  • I'm not really saying that it should be open season on new developments during the long freeze period, nobody will have capacity for that.
  • If there were more confidence that the changes during that freeze period would be small, that would be good, so I'm glad to hear that's the intention. 
  • Branching isn't actually that important either way, but it could be a way of stating that Moodle has confidence the changes will be small.
  • When code reopens, I'd like to see priority given to changes that were submitted a long time ago (over new developments). In other words, nothing new should go into the unfrozen code until the backlog's been cleared.

My feature MDL-44070 (with reduced scope) has now been submitted for review (although I haven't actually done Behat tests, which will happen over the next couple of days). Last I heard there was still a chance it could get into 2.7, but I'm not going to be remotely surprised if somebody now tells me different! (Also not sure if I need to beg Tim to peer-review it, which he probably wouldn't be impressed by, but anyhow...)

Which brings me to the last point. This is something we don't do that well at the OU either, but I think you should consider quoting some more dates, if only to manage expectations, and including these in the relevant documentation. In other words, if you're going to have rules about it, it would be good to document them. smile And does it mean integrated, submitted for review, or what. For example, instead of just code freeze = x, you could quote different dates:

  • major feature (>5k lines changed?) = submitted for integration (& passed) by x - 4 weeks
  • minor feature = submitted for integration (& passed) by x - 2 weeks
  • minor improvement = submitted for integration (& passed) by x -1 week
  • bugfix = submitted for integration (& passed) by x

One other thing that isn't really Moodle's problem and I'm not sure anything can be done about it, but it can make contributing more difficult for people employed elsewhere. Supposing a developer gets approval from their employer to develop a massive feature for core Moodle, so they put in several weeks or a month of work and get it done. But now there's a two-month pause before people review it and stuff - that means a bunch more work related to this feature is going to land on the developer's desk all of a sudden, but they're bound to have moved onto something else and it might now be difficult to fit it in...

--sam

 

 
Average of ratings:Useful (1)
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Thanks Sam,

There's a difference in focus though. You (Dan) say the changes after code freeze should only be bugfixes. For the OU system it's the same, but I think we're probably a little more strict - we say they should only be bugfixes discovered in testing the new release (or very shortly before the code freeze). In other words the code freeze isn't just a freeze for new features, it's a freeze for bugfixes too, unless those are bugs introduced by/discovered in testing of the new release. (Not saying we always stick to this, but we do a lot better than we used to.)

Actually, we do actually do an equivalent of this with priorities for changes integrated. The formal part of it is that we have a rule that qa blocking issues during the QA period get top priority by the integration team. Informally I think we also move our focus as a team towards considering issues which only affect the major release as a priority when getting closer to the major release.

So there was a massive swarm of bugfixes, some major, that all landed in the supposedly frozen code as fast as developers could code them. Is that happening in Moodle? (I have no idea.)

I don't think this is a particular trend in Moodle, though probably because everyone is working on the new features they are sneaking in during freeze :P

  • Branching isn't actually that important either way, but it could be a way of stating that Moodle has confidence the changes will be small.

That is an interesting idea - but what would be the benefit? To make it harder to make changes?

  • When code reopens, I'd like to see priority given to changes that were submitted a long time ago (over new developments). In other words, nothing new should go into the unfrozen code until the backlog's been cleared.

Completely agreed - MDLSITE-2892 should help with this.

For example, instead of just code freeze = x, you could quote different dates:

I agree this is a goal that we should be striving for. But:

  • We first need to get to the point where no 'major feature' is landing after the freeze date. (This hasn't happened yet, but watch for it this release, folks! :D). So i'd be happy integrating a huge change on the day of freeze right now, because..
  • The real difficulty is the pre-discussion and 'approval' of a big change, not so much the actual integration. In time it'd certainly be better to move towards that goal though.

can make contributing more difficult for people employed elsewhere

Yeah, I understand and sympathise with this problem. Many parts of the Moodle development process 'demand' time/attention from a developer in our timeframe and may not consider their schedule. In some cases it might be appropriate for Moodle HQ to take ownership of getting the feature integrated.

But at least the freeze/release period is scheduled in advance and consistent so can be planned for. The best advice is to have major features ready for integration on the day which Moodle opens for new developments smile I suspect that timely peer reviews/feedback/approval is more of a problem.

 
Average of ratings: -
Picture of sam marshall
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

Thanks Dan! I appreciate the response, as always. That all sounds good and I don't think there is anything major wrong with the approach in practice if you're moving toward a stricter code freeze. (Ideally, as that is achieved, that would also mean the strange 'on-synch' period after release can be reduced a bit as there are fewer unexpected problems.) And you're right that if we pay more attention to Moodle's dates when scheduling things we could avoid the problems associated with clashing schedules, at least in theory.

As for the question of the benefit of branching and whether it would make it harder to make changes after freeze - not really, no. I don't think there's a major practical benefit (assuming you're still going to avoid other changes on master anyhow) other than aligning with common practice, it's just more of a mindset thing, a reminder because it's different and marginally more effort than a normal change - 'oh this is the release branch so we shouldn't be making unimportant/major changes'. Say you do a bugfix your default behaviour is probably to submit it for master, so it makes that decision point clearer; 'Is this important enough/a regression so that I should submit it for the branch as well? Or should I just submit it for master like normal, in which case it will probably lurk around for a few weeks/months until we're back integrating master changes.'

(At the OU, we actually do allow people to do bugfixes directly to master, which won't go into the release, during that period. I.e. there is no effort to stay 'on synch'. But that might not be appropriate for Moodle.)

--sam

 
Average of ratings: -
Picture of Eric Merrill
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers

I don't mind the process in general, I just have two issues:

  • It can be hard to for an outside dev to get things peer reviewed. It would be nice if there was a 'review guarantee date' - maybe 2 or 3 weeks before freeze. Any tickets that are in requesting peer review status by this date will have a peer review done (and submitted by integration if it passes) by the code freeze date, and HQ will make sure that happens.
  • Second, and this is just a 'definition' issue. I've always been unclear if the published freeze date (4/7/14) is the date at which any feature tickets need to be in the 'waiting for integration' status (so the last new features will be integrated the week of 4/7-4/11), or they have to have been integrated by then (the last new features were integrated 3/31-4/4). I'm sure it's just me being dense, but it's always been unclear to me. Maybe it could use to have a definition somewhere in the docs.
 
Average of ratings: -
Picture of Justin Filip
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Testers

Yes, I'm unclear on this as well. It's an important question because I need to know whether we (RL) need to bang on something this weekend for 2.7 or if we have all of next week available.

We'd like to finish off something that had been waiting for a secondary peer review follow-up after languishing at or near the top of the PR queue for more than six months. An issue we were originally targeting for 2.6. =/

 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Hi Eric,

It can be hard to for an outside dev to get things peer reviewed

I completely agree. I don't think a deadline really is the solution though.. I'm going to start a new thread on this topic, having seen the really interesting discussion on this thread!

I've always been unclear if the published freeze date (4/7/14) is the date at which any feature tickets need to be in the 'waiting for integration' status, or they have to have been integrated by then

Yeah, we need a better way to define it, I think we've even gotten confused in the team about that! Its the former. Your code needs to be waiting for integration on 7/4/14. Can anyone think of a better set of words to describe this? In our calendar it says "Code freeze - all code must be 100% submitted!" - not sure that helps either though!

 
Average of ratings: -
Picture of Eric Merrill
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers

I'm not sure on a short set of words, but the definition could be something like "The last integration round with new features starts on this date".

There might be enough happening around code freeze that it could have it's own dev wiki page (with a definition, timelines, what can still happen while code freeze is in place, etc), and then you can link to that page.

 
Average of ratings: -
My ugly mug
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

This is a great conversation. Thanks for starting this, Dan. Thanks also to those involved.

I'm about to announce the code freeze (coming in one week from today), so I thought I would attempt to capture and justify the events happening during cycles, including code freeze and the on-sync period.

http://docs.moodle.org/dev/Process#Events_during_cycle

 
Average of ratings:Useful (1)
Picture of Aaron Barnes
Re: Do you find the code freeze/on-sync period problematic?
Group Developers
Hi all,

I have a few cents to add smile

Expanding on a brief twitter conversation I had with Dan, here are some thoughts (although not necessarily coherent, or valid):


I know this is me living in a perfect world, but in my humble opinion a "successful" code freeze period prior to a release should be quiet on the development front, with minimal (or almost no) bug fixes and code changes being made leading up to the release deadline. Last minute fixes are always risky, and I think we should be aiming to minify the changes that occur in this period.

Now, this is all well and good to say but another thing to have happen in practice.

To achieve this, the codebase would need to be "release-grade" stable at all times - so that when the code freeze begins we are very comfortable with the quality of the code. To achieve this, a lot the current QA-cycle would need to be moved into the weekly cycles. This means far more attention and effort is put into testing as changes are integrated into the current master (or MOODLE_XX_STABLE) branch.

I like the idea of this as I hope it brings up issues sooner and forces the QA process to become far more efficient and effective. It also gives me more trust in the quality of point releases - as they do not currently go through the same strict testing that major releases are put through. Hopefully, this would also remove the issue of large changes being rushed into the code base at the last minute before a freeze - as they would not be accepted into the release unless they had passed a thorough integration QA-round before the code freeze had started.

Again, all wishful thinking.

Currently, QA testing is required (and takes so long) because it's integration testing - it takes a tremendous amount of time to be relatively sure that every individual change that's been added does not break any other existing code, but with the continuing additions of Behat tests I believe this will become easier, quicker and safer. If we were doing thorough testing at integration, one potential way of lower the workload would be that at the integrators discretion we could test changes with lower levels of thoroughness depending on their perceived risk.

Spreading QA out would take far longer using the current method, so obviously this approach would require (and only work) with a big rethink and optimisation of testing - something I'd love to discuss more.


So if all the testing is spread out, what is the point of the code freeze? Well it gives us time to check (and update) documentation (as the API and UI will have stabilised for that major release), gives the translators a "string freeze", contrib module developers time to make sure their modules work with the upcoming release and just more time to run through the general process of getting a release out.


Again, this is really just a brain dump and I'm certain I'm probably way off-point on a lot of these points, but I just wanted to put them out there in case they inspire any brilliant ideas smile


Oh, one last thing... regarding the requirement of an on-sync period - isn't this indicative of us doing version numbers / database upgrades wrong? Surely if it's enough of an issue that we need to freeze the branch for 3 weeks we should look at ways of mitigating the issue?


Anyways - keep up the great discussion!

Cheers,
Aaron
 
Average of ratings: -
Picture of sam marshall
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

Re whether version numbers are 'wrong' - I think/hope most people involved with Moodle probably realise that a 2.x.0 release (e.g. during that 'on synch' period) is a beta in all but name...

--sam

 
Average of ratings: -
Picture of Eric Merrill
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Particularly helpful Moodlers

I think he means that we are doing DB upgrades the wrong way - eg we avoid schema changes because there may be duplicate upgrade paths, etc.

Personally I agree - I think the current upgrade system is quite limited. Maybe every modification (or group of them applied together) gets a serial number, and then you track which serials have been applied, I don't know. I just know the current method is a bit flawed.

 
Average of ratings: -
Picture of Aaron Barnes
Re: Do you find the code freeze/on-sync period problematic?
Group Developers
Hi Eric,

That's exactly what I meant smile But Sam brings up a great point too!

Cheers,
Aaron
 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers
Note that this is exactly the situation we are trying to move away from, though.
 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Do you find the code freeze/on-sync period problematic?
Group DevelopersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup Testers

Hi Aaron,

Basically we are in agreement and I think you are missing some of the effort which is already taking place to move towards the ideal you are talking about. smile

the codebase would need to be "release-grade" stable at all times [...] To achieve this, a lot the current QA-cycle would need to be moved into the weekly cycles.

This is a goal and it is already happening with our automated acceptance tests (behat) which are running weekly for exactly that purpose. See MDLQA-5249 where about 1/4 of the existing QA tests have been converted to automated tests (and i'm fairly sure thats an incomplete list).

 
Average of ratings:Useful (1)
Picture of Aaron Barnes
Re: Do you find the code freeze/on-sync period problematic?
Group Developers
Hi Dan,

Thank you for your response, I'm happy you agree! This fills me with much hope smile

I know you guys are working hard to improve things - I'm glad we're in agreement about the direction!

Cheers,
Aaron
 
Average of ratings: -