On 09/27/2013 01:06 PM, Siebrand Mazeland wrote: 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. 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. -- Mark A. Hershberger NicheWork LLC 717-271-1084

On 09/27/2013 01:52 PM, James Forrester wrote: 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. -- Mark A. Hershberger NicheWork LLC 717-271-1084

On 09/27/2013 03:42 PM, Chad wrote: 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? -- Mark A. Hershberger NicheWork LLC 717-271-1084

Unsubscribe Sent from my iPhone