What is the right schedule for Koa?

Working Groups Build-Test-Release
1

Since we decided on disciplined six-month releases, and Juniper arrived on June 9th, Koa should ship on December 9th.

How long do we want for testing the Koa master branches before that release? Four weeks would mean creating the master branches on November 11th. Is four weeks the right amount of time?

1 Like
2

By “testing” you mean working with koa.master before tagging a koa.1, right? If yes, four weeks seem to be a nice amount of time to test it. :+1:

3

(Again, sorry for not noticing this earlier, I’m going to work on a “How to enable forum notifications” post)

Yes, I think it is. For Juniper, four weeks was just right – even though we eventually went beyond schedule to announce the release, most of the testing was done during those first four weeks. For Koa, I did some initial testing and I expect that fewer issues will arise.

Thus, I’d like to propose the following schedule:

  • 2020-09-27T22:00:00Z: start testing the master branches to detect major changes early. We should not spend too much time on this, as the master branch is likely to change drastically before the code freeze. However, I’d like to have a very rough idea of what’s to come in Koa. In particular:
    • Which dependencies (Mongodb, MySQL, Python, Nodejs…) were upgraded?
    • Are there any new IDAs or MFEs?

Answering these questions will help us have a clue of what’s to come in Koa, as we still don’t have a changelog for Open edX. (yes, I will keep highlighting this fact in a passive-aggressive manner until it is no longer true)

  • 2020-11-08T23:00:00Z: feature freeze, creation of the open-release/koa.master branch. The community starts testing and reverse engineering the new release, fix bugs. Note that we will not be creating “open-release/koa.alphaX” tags.
  • 2020-12-08T23:00:00Z: publication of the open-release/koa.1 tag, announcement, champagne :champagne:
1 Like
4

@sambapete I suggest that we move here the conversation about release tags during the testing phase. Your comment here clearly emphasized the importance of tags for you during testing. We initially agreed not to use “open-release/koa.alphaX” tags, but we can go back to that decision.

This was a suggestion that @nedbat made here (and which blew my mind because I had no idea this was even possible with git). I think this could be a reasonable alternative to pre-release tags, assuming we all agreed on a given date to do our testing. But I also wouldn’t mind resorting to “*.alphaX” or “*.rcX” tags again.

What do you think @sambapete?

5

BTW: I tried using the fancy git syntax, but it won’t work for the installation process, since it tries to use it in GitHub urls, and they won’t accept it… :frowning:

6

@regis @nedbat That was indeed a nice suggestion. We would still have needed to make sure that all repos were set with the same fixed point in time. Unless the syntax was clearly independent of the last time you updated master and gave you a snapshot of the state of master at the end of a very particular calendar day. I am thinking of multiples updates of master on a specific day, which one does it take? The first one? The last one?

To be honest, I was curious how the fancy git syntax would survive the native installation process :disappointed:

7

So, do we all agree to use “alphaX” tags again during the testing process?

8

I believe it is reasonable. Both for my own needs (rebasing with our fork) and to make sure we all test against well known tags.

9

Fine with me.