BLR Website release: date?

[myrmoteras]

What is the forseen BLR website release?

We need to get it out be end of this week so we can report it May 14 in the Arcadia report.

Do you want to release it quietly so we can fix bugs, etc. or shall we write a comment in the Plazi new section?

[punkish]

It is up to @tcatapano and @teodorgeorgiev, whatever they decide. But yes, I agree that it should be put in production soon so we can continue testing it on the different server, and also mention it in the report. Small bugs, etc. can be fixed as time goes on.

one thing to note, I still have not been able to update the db to the latest data. I am working on the routines, and soon as that gets done, I will update the data. It will not affect the API or the website other than showing more recent records. Unfortunately, I can't promise a date for it, but I hope I can complete it in a few days.

[tcatapano]

@myrmoteras: If you mean by release, the promotion to the production server of the current release candidate on the staging server, then this can be done at any time. It would need to be approved for release by you as you are the principal stakeholder. The promotion itself would be need to be done by @teodorgeorgiev who would need to point the website app to https://zenodeo.punkish.org/v2 and move to the host serving http://biolitrepo.org/ and @punkish who would need to deploy the release candidate of his code currently on host serving http://z2.punkish.org/v2 to the one serving https://zenodeo.punkish.org/v2.

If what is meant by release is "ready to be publicized" or "hard launched", again this is up to you. In my opinion we are still in a "soft launch" period, but it is entirely not a technical question.

[myrmoteras]

I think we should promote to the production server, hopefully with some of the suggested issues resolved, especially the links to ocellus, synospecies, openbiodiv, that is applications that are based on BLR data (BLR in the modern sense of data produced by TreatmentBank and available for further development using the APIs or other access points.

In fact we need to do it for our Arcadia goals.

The hard launch must be our next goal after May 14 as soon as possible

So, if @teodorgeorgiev and @punkish also agree, then promote to the pruduction server.

[punkish]

ok, sounds like it is a go-ahead from @tcatapano. Re. @myrmoteras saying yay or nay, sounds to me that he is itching to say yay. From a functionality point of view, he had all this time to chime up with objections but didn’t. And, since no one has reported any further errors, perhaps we should go ahead. This means steps in this order:

1. I package the RC-2.6.1 to release v2.6.1 and pull the code on to the Zenodeo production server. Barring any unforeseen problem, I should be able to do it by late tonight or tomorrow.

2. Then it is matter of @teodorgeorgiev to update the production server for the website (wherever that is running) and point the code to Zenodeo.

Seems like we should easily have the whole thing going in a day or two latest. That gives us a lot of time to whack at it while the API and the website both are being served from their respective production instances before we send the 2020 report to Arcadia.

And yes, soft launch is the term I was seeking. Perhaps this first time, let’s do it quietly, get used to the process, and then make a noise.

On May 4, 2020, at 6:05 PM, tcatapano notifications@github.com wrote:

@myrmoteras: If you mean by release, the promotion to the production server of the current release candidate on the staging server, then this can be done at any time. It would need to be approved for release by you as you are the principal stakeholder. The promotion itself would be need to be done by @teodorgeorgiev who would need to point the website app to https://zenodeo.punkish.org/v2 and move to the host serving http://biolitrepo.org/ and @punkish who would need to deploy the release candidate of his code currently on host serving http://z2.punkish.org/v2 to the one serving https://zenodeo.punkish.org/v2.

If what is meant by release is "ready to be publicized" or "hard launched", again this is up to you. In my opinion we are still in a "soft launch" period, but it is entirely not a technical question.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[punkish]

On May 4, 2020, at 6:14 PM, Donat Agosti notifications@github.com wrote:

especially the links to ocellus, synospecies, openbiodiv, that is applications that are based on BLR data (BLR in the modern sense of data produced by TreatmentBank and available for further development using the APIs or other access points.

For that you would need to give the appropriate text and instructions to @teodorgeorgiev so the BLR website can be modified accordingly.

[myrmoteras]

I did my testing - see the respective comments in the issues

Ok, @punkish let's agree on a the format for the description of the three applications. ie one paragraph and the link and get the tree applications included. @teodorgeorgiev @lyubomirpenev can you do this for openBiodiv?

@teodorgeorgiev I hope this is ok and can be included

[punkish]

Ok, @punkish let's agree on a the format for the description of the three applications. ie one paragraph and the link and get the tree applications included.

I will draft a para in a new issue so everyone can comment on it

[punkish]

I did my testing - see the respective comments in the issues

I am just now seeing these comments because I generally don't track the issues for the BLR website. I have too much on my hand with Zenodeo and I can't test BLR website as well.

That said, your comments are all great, a result of very helpful and thorough testing. I have been through only three of those as of yet and replied to them, and none of those three are BLR UI comments. They are really Zenodeo comments and should have been on the Zenodeo website. However, I can understand that as a user of the website, you don't know whether an issue is BLR or Zenodeo, so perhaps someone else should have moved them to Zenodeo so I would have been informed (or you could have tagged me).

Think of it this way – if you find something wrong with the website, how it looks, how it functions (like the sequence or behavior of buttons and fields and forms, etc.) whether the user experience is good or confusing, all that stuff is BLR related. Any thing that appears problematic with the data, that is very likely Zenodeo related, unless the BLR website is forming an incorrect query in the first place.

In any case, the three issues I replied to are all non-issues from my point of view because the queries are performing exactly as they were intended. But, that they are confusing to the user needs to be resolved, perhaps by providing more examples or explanations on the website.

I will continue to read those comments and respond to them. It will take me some time.

[teodorgeorgiev]

@myrmoteras we are ready to update http://biolitrepo.org/ at any time, please let me know when (it should happen of course after @punkish update https://zenodeo.punkish.org/v2) Please send me the description of the applications, we will write similar for openbiodiv

[myrmoteras]

@teodorgeorgiev, @punkish and reto Can you please have a quick look at this paragraph convering synospecies? https://docs.google.com/document/d/1zveUuK8xeIPh_anSgrsDgaz9ZheGXXjsrDqd-IzRt7I/edit thanks d

[myrmoteras]

@teodorgeorgiev @punkish This is the green light from @tcatapano and me to publish the current version of http://blr.uplaysandbox.website/, ideally with including the links to ocellus and synospecies (the text is here. Thanks

[teodorgeorgiev]

We will update the production site tomorrow. I guess the links to ocellus and synospecies have to be in the APIs section, right? @myrmoteras @tcatapano: What about the short descriptions? Do want me to add them also in the APIs section, or just the links?

[myrmoteras]

@teodorgeorgiev here is the note about synospecies https://docs.google.com/document/d/1zveUuK8xeIPh_anSgrsDgaz9ZheGXXjsrDqd-IzRt7I/edit

either in API as examples of how BLR data allows third party developments

[punkish]

no wait !!!

IMPORTANT

I will be pushing an update later this evening (hopefully if all goes well) that will have a breaking change. For various reasons, I will not update the major version of the API, but it will go from 2.6.x to 2.7.x.

Here is the change: the route /treatmentAuthors will change to /articleAuthors.

rationale: The reason is because (after a long conversation with @myrmoteras) I discovered that what I was calling treatmentAuthors in my schema was actually the author of the article in which the treatment appeared. Of course, the authorityName is the author of the treatment, and to make the difference between the two authors crystal clear, I now call the author of the article articleAuthor.

This is how the route info will look

{
    "name": "articleauthors",
    "description": "Fetch articleAuthors related to the treatment from Zenodeo",
    "path": "http://localhost:3030/v2/articleauthors"
  },

http://localhost:3030/v2/articleauthors will fetch 30 authors at a time, which can be constrained by /articleauthors?articleAuthor=fisher or /articleauthors?articleAuthorId=532A30FD59B054D838CD64EC07CC7C86` and so on

The reason I am not upping the major version number is because this is a long lived error that either should not have occurred or should have been caught a long time ago. It adds no new functionality and restores sense to the schema.

implication for apps such as BLR: in the selection box, you should change the word "author" to reflect exactly what you mean. I would actually suggest that you have both options, one for the "article author" (articleAuthor) and the other for the "treatment author" (authorityName). You will have to accordingly modify the query sent to zenodeo wherein author=??? will change to articleAuthor=???.

I hope this detailed explanation makes things clear. Please holler if anything is needs clarification.

Of course, I will inform here when z2 is updated. Then we should test the BLR sandbox for another day (@myrmoteras) and we can go to production on May 9.

cc @teodorgeorgiev @tcatapano

[tcatapano]

@punkish: Im very much of the belief that it is crucial to resist the urge to implement such last minute "wait! I can fix this one last thing" changes. I highly recommend we push what is currently deployed in the staging servers and promote to production together. Especially since this is a breaking change which will require work to be done on the web app end and all tested once again, let's maintain the release discipline. Remember, once a release candidates has been deployed on the staging servers, they should be STATIC until promoted to production or rejected. No intermediate hot fixes rushed from development.

Now, if this now regarded (principally by @myrmoteras) as a such a major bug that releasing the version of the website on staging would result in something worse than what is currently deployed in production (I doubt it; besides, that should not happen), then we should reject the current Release Candidates and redo the release cycle -- but not in a rush. We could isolate this one fix and push a single issue patch release to expedite, but again, let's proceed in an orderly way.

[punkish]

these are great arguments, very sensible and disciplined. I am inclined to follow them with no further questions. But I do think that this is a very special case. But first…

fwiw, I have the fix already working in a separate branch, and have been testing it. Actually, there is not much testing to do because it is a pretty straightforward change, as I described above in my detailed description. I think, assuming normal coding practices, it would be just as simple in BLR as well because it only involves changing the names of the params rather than any UX/UI.

If the decision were mine and mine only, I would make the change. This is not just because the change is for the better but also because I believe that we can very easily accomplish it in the time we have. In short, *in my view**, it is an error worth correcting and is also easily correctable.

However, I leave the decision to you and @myrmoteras, because we can also go with as is. Just be aware of the drawbacks – the resource route will be called something different from what it is, and unfortunately, that different name is misleading. To reiterate, what is currently called treatmentAuthors is actually articleAuthors. The reason this error came to light was because @myrmoteras reported non-intuitive results when searching for treatments by author.

Also, whether we go my way or your way, certainly the need for a disciplined development process can, should and will be centerstage.

[teodorgeorgiev]

the current version of http://blr.uplaysandbox.website/ is now published on http://biolitrepo.org/ and it points to https://zenodeo.punkish.org/v2/

[myrmoteras]

@teodorgeorgiev should it work? The search fucnctionality does not work.

Also, the synospecies and ocellus are not there in the API

[punkish]

This will not work. Please note that I haven’t yet moved the latest test version to zenodeo yet. I didn’t write any email or message saying “go ahead”.

I am in the middle of that and will probably finish in about 30 mins.

On May 8, 2020, at 2:22 PM, teodorgeorgiev notifications@github.com wrote:

the current version of http://blr.uplaysandbox.website/ is now published on http://biolitrepo.org/ and it points to https://zenodeo.punkish.org/v2/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[teodorgeorgiev]

yes, it should work ... however, now I see that the endpoint was changed to https://zenodeo.org/v2/ ... which is something that I did not expect to happen. With regards to the synospecies and ocellus, please send me clear instructions, where and how you want them.

[punkish]

sigh, this is what happens when there are cross-instructions via email. As I said very clearly, I will say when the move is complete. It is not yet complete. I can understand that you didn’t expect the domain change to happen because I was going to tell you when it was working properly. Please give me the time to finish the job as I cannot work under pressure, esp when I have said that I will let everyone know when the move is complete. I am still in the process of pushing the right release on the production server.

On May 8, 2020, at 2:32 PM, teodorgeorgiev notifications@github.com wrote:

yes, it should work ... however, now I see that the endpoint was changed to https://zenodeo.org/v2/ ... which is something that I did not expect to happen. With regards to the synospecies and ocellus, please send me clear instructions, where and how you want them.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[punkish]

ALL CLEAR

zenodeo v 2.6.4 is now running on production server. Please note the new URL

root https://zenodeo.org docs https://zenodeo.org/docs v2 https://zenodeo.org/v2/

cc @tcatapano @teodorgeorgiev @myrmoteras

[teodorgeorgiev]

@punkish, of course, you can change the host of the API endpoint, but this should be communicated in advance ... I did not hear a single word that you plan to do this ... and I am not talking about versions of the code or CR. ... guess if the link to Zenodeo documentation in the BLR's API page is correct now :) I am really sorry but it is not supposed to happen in that way cc @tcatapano @myrmoteras

[punkish]

You are absolutely correct, a change in the host name should be announced in advance. And that is exactly what I was going to communicate along with telling everyone that the production server is now ready. That way, my announcement would have been in advance. But I never got a chance to say, “Hey everyone, the production server is now running the latest version.” Anyway, water under the bridge. Going forward, let’s remember this ––

I will never change anything breaking before announcing it. And most of the times, I will actually wait for feedback before actually implementing a breaking change. Case in point, the discussion about changing the /treatmentAuthors to /articleAuthors. Yesterday (about 17 hours ago) we had a detailed back-and-forth right here on issues, and I waited for everyone’s response. @tcatapano responded to my long message, and I thought about it overnight. This morning I decided to followed what he was suggesting (not make the breaking change). But, I still had not pushed the latest code to the prod server. As I did that, I also made the domain change, and was planning to announce the two at the same time.

So, I will always announce a breaking change, or even the intent of a breaking change. Then, when and only when I actually implement it, only then will I announce that the said change is now active. And if it means any supported services might break, I will coordinate with the concerned parties so we can synchronize our activities.

Anyway, phew !! good job everyone. Glad to have this all working, and better now since we still have a week before we send the report to Arcadia and announce this to everyone.

Thanks Teodor. Let’s look forward to the next release.

On May 8, 2020, at 3:11 PM, teodorgeorgiev notifications@github.com wrote:

@punkish, of course, you can change the host of the API endpoint, but this should be communicated in advance ... I did not hear a single word that you plan to do this ... and I am not talking about versions of the code or CR. ... guess if the link to Zenodeo documentation in the BLR's API page is correct now :) I am really sorry but it is not supposed to happen in that way cc @tcatapano @myrmoteras

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.