On Thu, Sep 3, 2020 at 7:26 AM Robert Vogel wrote:
> For the BlueSpice distribution ...
>
> * we have got ~90 active repos hosted on WMF Gerrit and another ~10 in our
> internal Gitlab
>
> * we want to develop as much as possible on the public infrastructure of
> the WMF, so the remaining
On Fri, 28 Aug 2020 at 11:19, Daniel Kinzler 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.
The SIP is very well written, great work! Recently
Hi!
For the BlueSpice distribution ...
* we have got ~90 active repos hosted on WMF Gerrit and another ~10 in our
internal Gitlab
* we want to develop as much as possible on the public infrastructure of the
WMF, so the remaining internal repos will (hopefully) be published in the future
*
Thanks hashar, understood!
Greg Rundlett
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 28/08/2020 18:26, Greg Rundlett (freephile) wrote:
> 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
On 31/08/2020 18:58, Bill Pirkle wrote:
> A clear and straightforward policy for getting things "in" sounds great.
> However, this might encourage the addition of extensions that are
> ultimately abandoned and which themselves become a code maintenance burden.
> We should also consider our policy
Honestly if you want a depreciation policy, warnings need to be omitted for
at least one 1.x version. Anything less than that is pointless from an end
user perspective. We tend to wait for final releases to limit bug exposure.
If something breaks, and it's not clear exactly what the cause is,
Hi Arthur!
We were indeed thinking of different scenarios. I was thinking of someone who
runs a wiki with a couple of one-off private extensions running, and now wants
to update. They may well test that everything is still working with the new
version of MediaWiki, but I think they would be
Hi,
On 2020-08-28 02:18, Daniel Kinzler wrote:
> 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?
I think going down this road would be a mistake, mostly
Hmm, maybe we're talking past one another here? I'm assuming a developer of
an extension who is interested in testing a new release - if we have a
version that has things deprecated vs completely removed, that allows a
quick check to see if the deprecated code affects them without going back
into
Am 31.08.20 um 18:52 schrieb Arthur Smith:
> So the alpha
> release would have to be tested in a separate environment, with
> development
> warnings enabled, and someone actually looking at the log. Typically,
> people
> only look at logs after things break.
>
>
> Is that true?
>
> 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?
>
> So the alpha
> release would have to be tested in a separate environment, with development
> warnings enabled, and someone actually looking at the log. Typically,
> people
> only look at logs after things break.
>
Is that true? I thought deprecation warnings appeared directly when viewing
a
Am 28.08.20 um 21:47 schrieb Physikerwelt:
> I appreciate your argument, however, I think the deprecation policy
> will be used in good faith. Fast deprecations are really helpful for
> code that is not been used. If one expects that a feature is used in
> hidden code probably people will not
Am 28.08.20 um 17:51 schrieb Arthur Smith:
> Would it be feasible to put the deprecation notices in an early release
> candidate, then encourage third party extension creators to try the release
> candidate with deprecation notices so they'll see where there are problems
> in their code, and what
Hi Daniel,
I support your proposal.
Re: Ariel
I appreciate your argument, however, I think the deprecation policy
will be used in good faith. Fast deprecations are really helpful for
code that is not been used. If one expects that a feature is used in
hidden code probably people will not
Hi Greg, thanks for your reply!
Am 28.08.20 um 18:26 schrieb Greg Rundlett (freephile):
> I like the idea of streamlining deprecation and avoiding the cost of
> maintaining obsolete code. I also **want** to publish my code on Gerrit.
Just a quick clarification: while the current policy only
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
Would it be feasible to put the deprecation notices in an early release
candidate, then encourage third party extension creators to try the release
candidate with deprecation notices so they'll see where there are problems
in their code, and what they have to do to be ready for the final release
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
On 8/28/20 11:18 AM, Daniel Kinzler wrote:
Can we shorten or even entirely skip the deprecation process,
if we have removed all usages of the obsolete code from public
extensions?
I would support this, if only with the schadenfreude that MediaWiki will
become harder for
21 matches
Mail list logo
