We've come up with another document for interested people to review: the Backport policy[1].
Just as a process for reviewing RFPs was introduced this year, we've also set up a way to review requested backports. The first meeting to review these requests is in 2 weeks. In the meantime, have a look at the backport requests that we'll be reviewing[2].
[1] https://www.mediawiki.org/wiki/Project:Release_management/Backporting_policy [2] https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&a...
On Fri, September 27, 2013 18:41, Mark A. Hershberger wrote:
We've come up with another document for interested people to review: the Backport policy[1].
Just as a process for reviewing RFPs was introduced this year, we've also set up a way to review requested backports. The first meeting to review these requests is in 2 weeks. In the meantime, have a look at the backport requests that we'll be reviewing[2].
[1] https://www.mediawiki.org/wiki/Project:Release_management/Backporting_policy [2] https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&a...
Nice work, Mark. I've read the doc and added a link that I think may provide clarity.
Two things that are missing for me:
I can read how to indicate that I'd like to see something backported, but there is no way for me to find out when to expect a decision on if this will actually happen. Would it be possible to commit to a "will be reviewed within" time for "bugzilla issues with a merged patch in Gerrit that are marked as resolved fixed with the 'Backport_stable?' flag set'?
Secondly: Does this process only apply to MediaWiki core, or also to MediaWiki extensions that are tracked in Bugzilla.
Cheers!
Siebrand
On 09/27/2013 01:06 PM, Siebrand Mazeland wrote:
Would it be possible to commit to a "will be reviewed within" time for "bugzilla issues with a merged patch in Gerrit that are marked as resolved fixed with the 'Backport_stable?' flag set'?
Yes. We'll be reviewing them every two weeks and responding to all outstanding requests at that time. I've updated the policy with this information.
Secondly: Does this process only apply to MediaWiki core, or also to MediaWiki extensions that are tracked in Bugzilla.
We could use it for bundled extensions, but the process is currently intended only for the tarball distribution.
Still, if an extension is being used widely (and here, the data gathered from installation pings would be invaluable), then it would make sense to apply this process to other extensions tracked in bugzilla.
On 27 September 2013 10:36, Mark A. Hershberger mah@nichework.com wrote:
On 09/27/2013 01:06 PM, Siebrand Mazeland wrote:
Would it be possible to commit to a "will be reviewed within" time for "bugzilla issues with a merged patch in Gerrit that are marked as resolved fixed with the 'Backport_stable?' flag set'?
Yes. We'll be reviewing them every two weeks and responding to all outstanding requests at that time. I've updated the policy with this information.
Secondly: Does this process only apply to MediaWiki core, or also to MediaWiki extensions that are tracked in Bugzilla.
We could use it for bundled extensions, but the process is currently intended only for the tarball distribution.
Still, if an extension is being used widely (and here, the data gathered from installation pings would be invaluable), then it would make sense to apply this process to other extensions tracked in bugzilla.
What about for core changes needed by extensions that are widely-desired (I'm thinking specifically of VisualEditor here, but no doubt there are others), where our dependencies on MW 1.22 alpha (currently 1.22/wmf11https://www.mediawiki.org/wiki/Extension:VisualEditor) are almost all back-portable. We'd be interested in helping have VE run for MW other than bleeding edge for third party use - presumably by us (or some volunteer, hint hint) supplying patches for the relevant branch and flagging them to you two?
However, given the policy as written, these would only be accepted for LTS versions of MW (so, 1.19 and… eventually 1.22?) which is a bit unfortunate (or would the patches be accepted as and when a security release went out, but wouldn't trigger a release themselves?).
J.
On 09/27/2013 01:52 PM, James Forrester wrote:
What about for core changes needed by extensions that are widely-desired (I'm thinking specifically of VisualEditor here, but no doubt there are others), where our dependencies on MW 1.22 alpha (currently 1.22/wmf11https://www.mediawiki.org/wiki/Extension:VisualEditor) are almost all back-portable.
This is a good example.
Here is another: I noticed that a lot of questions showing up on the Support Desk had to do with Wikipedia templates, so I spent a small amount of time getting Scribunto to work with 1.19. (I'm sure there are lots of bugs in there, but it did work in my testing.)
So, yes, for cases like this it would make sense to backport these sorts of features even to to non-LTS versions. I did cover this briefly when I wrote that if "the requestor thinks it should be backported to non-LTS releases, they should say so in a comment."
If you have suggestions for how to improve the policy, I'm all ears.
For example, someone else thought this was too bureaucratic and less agile than it could be. I think, though, that the point of having a meeting every couple of weeks to handle backport reviews is to provide a definite time-line for when changes will be reviewed (as per Siebrand's question).
The review can happen before then, but the meetings are meant to serve as a definite point in time for the review in order to ensure that the reviews *do* happen.
Thanks,
Mark.
On Fri, Sep 27, 2013 at 12:20 PM, Mark A. Hershberger mah@nichework.comwrote:
On 09/27/2013 01:52 PM, James Forrester wrote:
What about for core changes needed by extensions that are widely-desired (I'm thinking specifically of VisualEditor here, but no doubt there are others), where our dependencies on MW 1.22 alpha (currently 1.22/wmf11https://www.mediawiki.org/wiki/Extension:VisualEditor) are almost all back-portable.
This is a good example.
Here is another: I noticed that a lot of questions showing up on the Support Desk had to do with Wikipedia templates, so I spent a small amount of time getting Scribunto to work with 1.19. (I'm sure there are lots of bugs in there, but it did work in my testing.)
So, yes, for cases like this it would make sense to backport these sorts of features even to to non-LTS versions. I did cover this briefly when I wrote that if "the requestor thinks it should be backported to non-LTS releases, they should say so in a comment."
If you have suggestions for how to improve the policy, I'm all ears.
For example, someone else thought this was too bureaucratic and less agile than it could be. I think, though, that the point of having a meeting every couple of weeks to handle backport reviews is to provide a definite time-line for when changes will be reviewed (as per Siebrand's question).
The review can happen before then, but the meetings are meant to serve as a definite point in time for the review in order to ensure that the reviews *do* happen.
I agree it's too bureaucratic. In fact, I'd propose we go a completely different route with backporting. If something needs backporting, it should land in the old branch first. Then we can occasionally just merge those branches forward to master.
-Chad
On 09/27/2013 03:42 PM, Chad wrote:
I agree it's too bureaucratic. In fact, I'd propose we go a completely different route with backporting. If something needs backporting, it should land in the old branch first. Then we can occasionally just merge those branches forward to master.
If we can land fixes on the old branches first, this makes a lot of sense.
The problem I see, though, is that now we have to train everyone who is going to fix code to put it on the oldest supported branch first instead of just fixing it in master.
So, yes, the policy to let bugs get fixed without too much effort while providing a process (also known as "bureaucracy") to ensure that the older code has a way of being supported.
But, if the process gets in the way and someone fixes the older code first and then merges the fix forward, they shouldn't be told to do it over and "follow the process." The policy is there to help deal with the current situation, not to provide a list of steps that *must* be followed.
Or maybe I'm not understanding what you're saying. Am I missing something?
In order to address concerns about the bureaucratic feel of the backport policy, I've added the following to the page:
== Do all backports have to go through this process? ==
No. Developers who have commit access can use the “Cherry Pick To” button to backport changes without using this process. This policy is so that people without commit access have a way to request fixes to code that they use.
HTH,
Mark.
Unsubscribe
Sent from my iPhone
On 29 Sep 2013, at 3:17 am, "Mark A. Hershberger" mah@nichework.com wrote:
In order to address concerns about the bureaucratic feel of the backport policy, I've added the following to the page:
== Do all backports have to go through this process? ==
No. Developers who have commit access can use the “Cherry Pick To” button to backport changes without using this process. This policy is so that people without commit access have a way to request fixes to code that they use.
HTH,
Mark.
-- Mark A. Hershberger NicheWork LLC 717-271-1084
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org