Thanks for getting this going. The format we have used at edX is, first, make lists of what went well, and what could have gone better. Then vote on which topics to discuss in more depth, then have those discussions.
An hour might be short, but we can schedule other times for deeper discussions of particular topics.
This makes sense I’ll kickstart the list with my own items.
The release candidates were created at sensible places in the git log, after some of the major technical components were successfully upgraded (Python 2.7 -> 3.5, Django 1.11 -> 2.2, Mongodb 3.2 -> 3.6, Ruby 2.5.7, Nodejs 8 -> 12).
The discovery of technical issues was an haphazard process, with every member of the working group trying to install the new release and discussing issues as they were discovered. It was a random easter egg hunt, and not a systematic search-and-destroy process. Still…
… the community did manage to detect and address issues efficiently. Members from the community tried the three release candidates and made sure that the installation process went smoothly. Issues were raised and listed in the CRI-171 Juniper epic.
Assigning the issues to the Juniper epic was a convoluted process that should be streamlined. It’s weird that non-edX users can create issues, but not edit their descriptions or assign them to the CRI-171 epic.
The Open edX community stepped up to the task of resolving the detected issues. There was a strong determination for producing a stable, reliable release.
Community pull requests were swiftly reviewed and merged in time for the Juniper release. However, since the release was made, things are back to the old normal and pull requests take many weeks to be reviewed and merged. (see mine for instance)
In many cases (static asset compilation, honor/audit course modes), edX employees went above and beyond to help fix complex issues that caused backward incompatibility, providing precious information and manpower to produce a fix.
I might be wrong, but in my understanding the community did not manage to do sufficient testing of the new release from the perspective of product design. That means that some features may be broken without us even knowing about it.
The Juniper release was scheduled for May 21st. It was finalized only on June 9th, with a 3 weeks delay. Still, I think this is a success, considering that most of the technical work was ready in time for the deadline. One of the items that caused that delay was the Mongodb upgrade. We should clarify how and why some members were aware of the upgrade, but not others; why the upgrade was not mentioned before in the Juniper notes; why the installation playbooks were installing an outdated version of Mongodb. It’s not all clear to me what other tasks needed to be performed between juniper.rc3 and juniper.1: I know that translations needed to be updated, and a Django security patch had to be applied. There is probably room for improvement to make sure that future minor upgrades (juniper.2, juniper.3, etc.) can be produced quickly and with minimal effort.
The Juniper release is a major technical improvement over Ironwood, but there are some regressions during the installation process. In particular, LMS database migrations take much longer (note to self: add a more precise metric here) in Juniper than in Ironwood. This is (probably) caused by the fact that we did not find the time to squash the database migrations in time for the release. Also, running webpack takes much longer and uses more memory, causing some servers to crash.
Finally, there is the elephant in the room: even after the release, the community as a whole has no idea what’s in Juniper, in terms of product features. We grope around, looking for new pages and visual cues for new features (see this blog post by IBL for instance) but to be honest we are still very much clueless. I am very much concerned that this issue will happen again with Koa, as the community still has zero insight in the features added to Open edX, nor in the EdX roadmap.
Despite the fact that this is the tenth Open edX release, there still isn’t a clear upgrade path from the previous release for users of the native installation scripts. This is completely unsustainable. The officially recommended installation method must have a clear upgrade path.
As of today, there still has not been any official announcement about the release by edX (see edX blog). This makes it much harder for the community to defend the Open edX brand and product.
It’s important to note that Juniper was released in an particularly difficult context: the entire online learning community was (and still is) mobilized to address the needs raised by the COVID-19 situation. Yet, there was an urgency to move away from Python 2.7 and Django 1.11 as soon as possible to avoid security issues. I think the community (and that includes edX) did the absolute best they could, under the circumstances. However, we really need to step up our game for Koa to address the most glaring issues in the release process. As far as I am concerned, I will need to make sure that issues #11 and #12 are properly addressed before I get involved in the release process of Koa.
I encourage others to add their own list of items before tomorrow’s discussion. To do so, just hit the reply button and add your answer to this topic.
(Geoffrey L. (OpenCraft) - opencraft.com/help)
Thanks for setting up the meeting @regis. While I would like to be at the meeting, I won’t be able to be here because of timezone, it will be around 1am where I am. Please record the meeting and share it after, so I can watch it ask for more details if needed.