Thanks @Nikerabbit for disabling updates! I have get to submitting patches myself yet.
But we've changed the plans towards this library, so please hold on with any possible further changes to the config of translatewiki. I will execute our decision regarding the library on Monday, and then get back and write what's the status here. Then we can see what needs to be done to translatewiki config, if anything. Sorry for confusion.
I was also considering just moving it into Wikibase.git. Packagist shows a handful of uses outside of Wikibase. Those seem no longer maintained etc though. Basically, with situation when something had too be done fast with this package, I went for something which unblocked the deployment of Wikibase, and left the decision on whether to merge it into Wikibase or not for later. I guess now this decision has been made :)
Investigation concluded: IDs like L1-F1 are to be used everywhere in the code. @daniel and @thiemowmde claimed there is no motivation to have a different object that would only repesent F1-alike IDs, so it is not going to be introduced.
Wed, Nov 15
I've copied over the table to the task description, so it is better visible. I've also added links to the actual patches tested, and added a column with some ratio measuring somehow how slower was the patched code compared to master.
good catch @Lucas_Werkmeister_WMDE. Whatever would be said about the task description, this part is clearly not relevant. Editing.
Tue, Nov 14
Thanks @Nikerabbit! Added @translatewiki user as a collaborator to the new repo. Github says awaiting confirm the email.
Mon, Nov 13
hmm, quite a number of odd failures, e.g.
unknown error: Chrome failed to start: exited abnormally
Fri, Nov 10
Thanks @zeljkofilipin! This is really looking good. We'll have a Jenkins IPs whitelisted and see what actually failures are actually there on test. This is most likely going to happen on Monday.
Thu, Nov 9
As this extension is under active development, I guess we might want to consider some automated approach here too (as in T180067)?
Not sure if I did it right, I guess autoloading test classes with composer is still fine?
Given the amount of classes involved, I guess having a list generated by script (having it fired pre-commit would be nice), or more clunky having a manually-maintained list but including some kind of test making sure all is there, would be nice in this case.
I am going to give this a stab, but as I am travelling I might not be able to do it in the next days, so please others feel free to go ahead and it better and faster!
Thanks @zeljkofilipin! I will try to look at those failures in more detail when I am on a stable network connection.
- We are going to implement T163724 using the concept of making Forms implementing EntityDocument interface, and FormId being HierarchicalFormIds. @thiemowmde and others: could you please create relevant sub-tasks (a.k.a. provide task break down) to T163724? Possibly, this means using T163724 and friends but I am not sure how good they fit to the actual implementation. I'd prefer to create new tasks if existing ones are not 100% accurate than saving couple of minutes and try to "re-use" existing tickets which are kind of accurate but not exactly
- If all items of Wikidata-Test-Sprint are finished and there is still time left in the iteration, we are going to do an alternative implementation where no changes to the Data Model library are made. This does not mean doing exactly what T179662 made, but making "proper" implementation (not a proof of concept).
Wed, Nov 8
This could be closed, no? /ping @Addshore
Tue, Nov 7
oh, wait. Looking a screen caps it looks like those failures of the test job happen far before even starting to test anything. Is it intentional?
So it seems @zeljkofilipin that the beta job run without failures but there are 95 failures on test job. I guess still have plenty of stuff to look into then?
Mon, Nov 6
Thanks @daniel and @Smalyshev for the feedback so far.
Submitted https://github.com/wmde/WikibaseDataModel/pull/767 to get those changes made. Feel free to review and comment wherever you find applicable.
Unstalling this. Some changes suggested in the benchmarking ticket has been made: https://github.com/wmde/WikibaseDataModel/pull/767and this is now back in the game.
Fri, Nov 3
Thanks @Ladsgroup for running another round of benchmark.