Create GitLab Repository for the Wikistats2 service, using the other AQS 2.0 service repositories as an example. Populate with the Go service scaffolding as a starting point, with boilerplate suitably modified as necessary.
Completion criteria: the repository is ready to accept merge requests for endpoint and unit test implementation.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T324931 Clean up open RESTBase related tickets | |||
| In Progress | None | T262315 <CORE TECHNOLOGY> API Migration & RESTbase Sunset | |||
| In Progress | • DAbad | T263489 AQS 2.0 | |||
| Invalid | BPirkle | T288301 AQS 2.0:Wikistats 2 service | |||
| Invalid | FGoodwin | T317728 AQS 2.0: Wikistats2: Create and initialize GitLab repository |
@BPirkle: Is this about moving Wikistats2 currently located at https://gerrit.wikimedia.org/g/analytics/wikistats2 , or is this a different codebase with the same name (which would be confusing and great to avoid)?
@Aklapper , thanks for making the title more specific. Your work in keeping Phab clean is always appreciated!
@BPirkle: Is this about moving Wikistats2 currently located at https://gerrit.wikimedia.org/g/analytics/wikistats2 , or is this a different codebase with the same name (which would be confusing and great to avoid)?
Disclaimer: you may already be familiar with the history of Wikistats2. If so, reading the following is likely a waste of your time.
This is about the replacement codebase. The existing wikistats2 is implemented (along with the rest of the AQS service) on a very old fork of RESTBase. Because we are sunsetting RESTBase, the old code has to be replaced with a new one.
You might ask: why didn't we call it "wikistats3", to disambiguate? Somewhat confusingly, "Wikistats2" is more of a product name than product+version. As I understand it (and I wasn't around for this part, so I may have some things wrong), "Wikistats" was created by a volunteer quite some time ago and became popular. When that arrangement ended, WMF kept it going under the name "Wikistats2". And that name has kind of taken on a life of its own.
Due to RESTBase sunset, we're now creating a new implementation of Wikistats2 in a completely different language (golang instead of javascript), but we're (hopefully) keeping the API (which is what clients care about) 100% compatible. From a client perspective, the less that changes, the better. Our goal is not to add new features or rethink what Wikistats2 provides, or anything like that. Our goal is completely technical and internal.
You might still say "it should have its own name". And maybe you'd be right. I'm not sure there's a pressing need to keep the name the same (it doesn't actually appear in the urls or anything, so clients shouldn't really care what we call it). The counter argument is that, while yes this is "a different codebase with the same name", it is the new codebase for the same project, and you shouldn't change a project name just because you changed its implementation details.
I've typed a lot of words, so I'm going to stop now. I'd be interested to hear what you think about naming, given that background info.
Repository has been created at https://gitlab.wikimedia.org/repos/generated-data-platform/aqs/wikistats-2
Still needs an initial merge request to remove the service scaffolding boilerplate and be ready for actual Wikistats 2 changes.
Wouldn't be the end of the world if (per incomplete conversation above with Andre) we decided to rename and/or split this up before release - that'd mostly be cut-and-paste work.
@BPirkle: Thanks a lot for taking the time to explain, I did not know most of that!
I'd highly highly recommend not to mingle lots of different stuff under a single API Platform Phab tag but use dedicated project tags for dedicated codebases. (Bonus: You can easily filter workboards by that additional project tag instead of having to look at task summary prefixes.) Especially because WMF has a tradition of renaming projects, reorganizing teams, changing scopes, etc etc. It's way harder for potential contributors to understand which tickets are actually about some [sub]project/codebase, or to clean up later in case some [sub]project may get canceled. "Divide and conquer", basically.)
(Plus just for consideration, "Wikistats" is already a pretty overloaded name (cf VPS-project-Wikistats) and I'd prefer not to increase ambiguity if avoidable.)
This task is invalid.
We already have a GitLab repo, for Wikistats 2, but it should eventually be retired/abandoned. That should not happen yet, because we have exploratory code in that repo that we do not want to lose. But we are going a different direction with this.
Instead of one Wikistats 2 repo, we will have the following two gerrit repos:
Making tasks for creating those two repos is on my to-do list.