I like the idea of streamlining deprecation and avoiding the cost of maintaining obsolete code. I also **want** to publish my code on Gerrit.
As a 3rd-party extension developer who doesn't write a lot of code, one of the biggest complaints that I have is that it's "hard" to publish your work in Gerrit (and benefit from the visibility of being in the MediaWiki ecosystem). It's very easy to create a new repo at GitHub. It would be wonderful if there was some facility to "import" GitHub repos into Gerrit. (aside: I just read the gerrit TL;DR [1] and like how it's concise and to the point.) The same goes for gerrit code review. It's easy to create or review pull-requests on GitHub, but unfamiliar/awkward in Gerrit. I understand that a transition to GitLab is underway, and welcome the usability improvements that I anticipate from that. Of course I don't expect WMF to be able to duplicate the GitHub experience, but the more that can be done to improve the contribution workflows, browser-based interaction, and collaboration or integration with GitHub; the better. This may all seem tangential to the topic of the Stable Interface policy, but I believe there is a substantial "invisible" ecosystem of extensions developed by third-party developers. Most wikis I've encountered have developed in-house extensions of some kind. The harder it is for them to maintain their code to conform with MW development and deprecations, the more 3rd-party wikis will move to alternatives like Confluence or Microsoft SharePoint. [1] https://www.mediawiki.org/wiki/Gerrit/Tutorial/tl;dr Greg Rundlett https://eQuality-Tech.com https://freephile.org On Fri, Aug 28, 2020 at 7:41 AM Ariel Glenn WMF <ar...@wikimedia.org> wrote: > I'd like to see third party users, even those not on the mailing list, get > advance notice in one release (say in the release notes) so that when the > next release shows up with the deprecated code removed, they have had time > to patch up any internal extensions and code they may have. > > I don't want to penalize third parties who may not publish their extensions > because they think the code is not good enough for public consumption or > because it is very specific to their company or workflow. > > I also don't want to encourage delays in updating, or the common practice > of running very outdated versions of MediaWiki. Of course some folks will > remain on LTS; that's what it's there for. But once a new release is out, > we should want parties to be in a position to update to it immediately, at > least as far as our processes go. > > A delay of two releases is nice but not necessary and honestly I'd just > skip that altogether. > > Just my .02 €, > > Ariel > > On Fri, Aug 28, 2020 at 12:19 PM Daniel Kinzler <dkinz...@wikimedia.org> > wrote: > > > Hi all! > > > > Since the new Stable Interface Policy[1] has come into effect, there has > > been > > some confusion about when and how the deprecation process can be > > accelerated or > > bypassed. I started a discussion about this issue on the talk page[2], > and > > now > > I'm writing this email in the hope of gathering more perspectives. > > > > tl;dr: the key question is: > > > > Can we shorten or even entirely skip the deprecation process, > > if we have removed all usages of the obsolete code from public > > extensions? > > > > If you are affected by the answer to this question, or you otherwise have > > opinions about it, please read on (ok ok, this mail is massive - at least > > read > > the proposed new wording of the policy). I'm especially interested in the > > opinions of extension developers. > > > > > > So, let's dive in. On the one hand, the new (and old) policy states: > > > > Code MUST emit hard deprecation notices for at least one major > > MediaWiki version before being removed. It is RECOMMENDED to emit > > hard deprecation notices for at least two major MediaWiki > > versions. EXCEPTIONS to this are listed in the section "Removal > > without deprecation" below. > > > > This means that code that starts to emit a deprecation warning in version > > N can > > only be removed in version N+1, better even N+2. This effectively > > recommends > > that obsolete code be kept around for at least half a year, with a > > preference > > for a full year and more. However, we now have this exception in place: > > > > The deprecation process may be bypassed for code that is unused > > within the MediaWiki ecosystem. The ecosystem is defined to > > consist of all actively maintained code residing in repositories > > owned by the Wikimedia foundation, and can be searched using the > > code search tool. > > > > When TechCom added this section[3][4], we were thinking of the case > where a > > method becomes obsolete, but is unused. In that case, why go through all > > the > > hassle of deprecation, if nobody uses it anyway? > > > > However, what does this mean for obsolete code that *is* used? Can we > just > > go > > ahead and remove the usages, and then remove the code without > deprecation? > > That > > seems to be the logical consequence. > > > > The result is a much tighter timeline from soft deprecation to removal, > > reducing > > the amount of deprecated code we have to drag along and keep functional. > > This is > > would be helpful particularly when code was refactored to remove > > undesirable > > dependencies, since the dependency will not actually go away until the > > deprecated code has been removed. > > > > So, if we put in the work to remove usages, can we skip the deprecation > > process? > > After all, if the code is truly unused, this would not do any harm, > right? > > And > > being able to make breaking changes without the need to wait a year for > > them to > > become effective would greatly improve the speed at which we can > modernize > > the > > code base. > > > > However, even skipping soft deprecation and going directly to hard > > deprecation > > of the construction of the Revision class raised concerns, see for > instance > > < > https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg92871.html > > >. > > > > The key concern is that we can only know about usages in repositories in > > our > > "ecosystem", a concept introduced into the policy by the section quoted > > above. I > > will go into the implications of this further below. But first, let me > > propose a > > change to the policy, to clarify when deprecation is or is not needed. > > > > I propose that the policy should read: > > > > Obsolete code MAY be removed without deprecation if it is unused (or > > appropriately gated) by any code in the MediaWiki ecosystem. Such > > removal must be recorded in the release notes as a breaking change > > without deprecation, and must be announced on the appropriate > > mailing lists. > > > > Obsolete code that is still used within the ecosystem MAY be > > removed if it has been emitting deprecation warnings in AT LEAST > > one major version release, and a best effort has been made to > > remove any remaining usages in the MediaWiki ecosystem. Obsolete > > code SHOULD be removed when it has been emitting deprecation > > warnings for two releases, even if it is still used. > > > > And further: > > > > The person, team, or organization that deprecates code SHOULD > > drive the removal of usages in a timely manner. For code not under > > the control of this person, team, or organization, appropriate > > changes SHOULD be proposed to the maintainers, and guidance SHOULD > > be provided when needed. > > > > Compared to the old process, this puts more focus on removing usages of > > obsolete > > code. Previously, we'd often just wait and hope that usages of deprecated > > methods would vanish eventually. Which may take a long time, we still > have > > code > > in MediaWiki that was deprecated in 1.24. Of course, every now and then > > someone > > fixes a bunch of usages of deprecated code, but this is a sporadic > > occurrence, > > not designed into the process. > > > > With the change I am proposing, whoever deprecates a function also > commits > > to > > removing usages of it asap. For extension developers, this means that > they > > will > > get patches and support, but they may see their code broken if they do > not > > follow up. > > > > > > Now, my proposal hinges on the idea that we somehow know all relevant > code > > that > > needs fixing. How can that work? > > > > When TechCom introduced the idea of the "MediaWiki ecosystem" into the > > policy, > > our reasoning was that we want to support primarily extension developers > > who > > contribute their extensions back to the ecosystem, by making them > > available to > > the public. We found it fair to say that if people develop extensions > > solely for > > their own use, it is up to them to read the release notes. We do not need > > to go > > out of our way to protect them from changes to the code base. > > > > Effectively, with the proposed change to the policy, maintainers of > public > > extensions will get more support keeping their extensions compatible, > while > > maintainers of private extensions will receive less consideration. > > > > It seems desirable and fair to me to allow for "fast track" removal of > > obsolete > > code, but only if we create a clear process for making an extensions > > "official". > > How exactly would an extension developer make sure that we know their > > extension, > > and consider it part of the ecosystem? In practice, "known code" is code > > accessible via codesearch[5]. But how does one get an extension into the > > codesearch index? There is currently no clear process for this. > > > > Ideally, it would be sufficient to: > > * create a page on mediawiki.org using the {{Extension}} infobox, > > * setting the status to "stable" (and maybe "beta"), > > * and linking to a public git repository. > > > > It should be simple enough to create a script that feeds these repos into > > codesearch. A quick look at Category:Extensions_by_status category tells > > me that > > there are about a thousand such extensions. > > > > > > So, my question to you is: do you support the change I am proposing to > the > > policy? If not, why not? And if you do, why do you think it's helpful? > > > > > > -- daniel > > > > PS: This proposal has not yet been vetted with TechCom, it's just my > > personal > > take. It will become an RFC if needed. This is intended to start a > > conversation. > > > > > > [1] https://www.mediawiki.org/wiki/Stable_interface_policy > > [2] https://www.mediawiki.org/wiki/Topic:Vrwr9aloe6y1bi2v > > [3] https://phabricator.wikimedia.org/T193613 > > [4] https://phabricator.wikimedia.org/T255803 > > [5] https://codesearch.wmcloud.org/search/ > > > > -- > > Daniel Kinzler > > Principal Software Engineer, Core Platform > > Wikimedia Foundation > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
