On Fri, Jun 29, 2012 at 3:58 AM, Petr Bena <benapetr(a)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
[1]
http://wikitech.wikimedia.org/view/Software_deployments