On Fri, Jun 29, 2012 at 3:58 AM, Petr Bena benapetr@gmail.com wrote:
Can we create a new branch which would be speedily merged when changes were done to it, so that we could check out on labs and apply the change there in order to test if patches submitted by devs works ok? Thanks to Antoine we use the same repository on beta project, but right now it's really hard to test stuff submitted to gerrit because we need to merge stuff by hand.
I think we need to keep beta labs reasonably close to "near production" state. We made an exception for Timed Media Handler, but generally speaking, we want to have an environment that doesn't have a lot of experimental stuff. If we mix up a lot of different people's experiemental stuff there, then it will diminish the value of the bug reports that come out there.
Here's my thoughts on what we should be doing there: * Always stay up to the very latest version of master, preferably automatically * Only deploy extensions which have a scheduled release window[1] * For items that are a little more experimental in nature, we should deploy new feature wikis in the beta cluster. (e.g. crazyfeature.beta.wmflabs.org ). Note, these still need to run on the same codebase, so anything needed by crazyfeature needs to be in master, guarded by a runtime feature flag if necessary
Given how hard it has been to keep beta labs in any sort of functional state, encouraging unreviewed and experimental code moves this from "beta" to "alpha", and makes it pretty much useless for the type of integration testing that we need to do. Note, even as we speak, the beta.wmflabs.org redirect points to a non-existent instance.
Petr, I'm a little alarmed by this statement: "we need to merge stuff by hand". What do you mean by "merging by hand", and what sorts of things are you merging?
Rob