On Fri, Sep 27, 2013 at 12:20 PM, Mark A. Hershberger <[email protected]>wrote:
> 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/wmf11<https://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 _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
