On 2013-02-22 2:37 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Fri, Feb 22, 2013 at 8:24 AM, Mark A. Hershberger mah@everybody.org
wrote:
On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote:
will Chris be able to make and push tarballs for those even if they're not (only) security-related?
I can make and push tarballs without involving Chris.
And further, I'm planning *not* to push tarballs unless they are security related (unless for some reason Mark needs me to help out on a particular release, which I'm always happy to do).
But yes, we need to discuss policy, and start setting expectations, etc.
Can we build off the conversation you've started? That is, can you drive this conversation?
Does anyone else have thoughts about Nemo's ideas for release
expectations?
I don't have much to add, other than after the last security release, we've been planning to keep security and feature releases reasonably separate. This is so a user who only wants security patches doesn't have to find the security relevant parts of the patch. It also keeps changes to a minimum with security fixes, so it's less likely that an admin will need to revert the security fix if it breaks their install. But, this means more updates for users to install in general. Is that the preferred trade-off? Currently, all of our tools build the tarballs from the git REL branches, so keeping security releases entirely separate means we have to be more careful about what we push into that branch, to make sure it's always ready to have a release made if we need to do a security release.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I still would like to see critical bug fixes in next point releases including security releases. For example I would like to see the fix for the bug where wfSuppressWarnings turns on warnings that werent previously enabled, in php 5.4, instead of turning off the warnings to be included in the next point release. (Since the breakage is quite significant imo)
I personally would also like to see up to date i18n files in every release regardless of type. Otherwise third parties will never see i18n fixes.
-bawolff