into trunk. This
new branch cannot just these localisations from the trunk SVN because they
can be different. The key question for me is "how is this going to work". I
do not see it. The LocalisationUpdate extension might do the trick ...
Thanks,
GerardM
2009/7/14 Chad <innocentkiller(a)gmail.com>
On Tue, Jul 14, 2009 at 7:30 AM, Gerard
Meijssen<gerard.meijssen(a)gmail.com> wrote:
Hoi,
When the updates for "Wikimedia life" have to go into this new branch,
what
is then the status of the trunk? Will all the
updates *have* to go into
trunk as well and will they ? Or will trunk suffer from bit rot and
consequently will everyone work on this new branch ? What will be the
status
of the extensions NOT used by the WMF ?? When an
update to a new release
happens, will trunk and this new branch be merged and how will the
effects
on extensions be assessed ???
How will this work ?
Thanks,
GerardM
2009/7/14 Brion Vibber <brion(a)wikimedia.org>
> Since we seem to routinely have our deployment linger a bit behind trunk
> but still need to make updates on it, I've gone ahead and created a
> branch with out live versions of MediaWiki & extensions on it:
>
>
http://svn.wikimedia.org/svnroot/mediawiki/branches/wmf-deployment
>
> Misc coders: please don't commit to it or we break you. :)
>
>
> With Subversion 1.5 or later on the client, merging updates from trunk
> should be easier, as SVN now saves merge info into properties and can
> more intelligently figure out where you last left off. For instance to
> update the UsabilityInitiative extension to the current version from
trunk:
>
> cd extensions/UsabilityInitiative
> svn merge \
> svn+ssh://
>
svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/UsabilityInitiative
> svn commit
>
>
> The theoretical workflow is:
> * Merge updates that need to go live into branches/wmf-deployment
> * Test it locally & on staging server (once we've got a nicer staging
> area set up)
> * Update deployment master: svn up
> * Poke live test on
test.wikipedia.org
> * Deploy updates to all servers: scap
>
>
> For the moment I've applied the various 'svn up' and manually merged
> live patches from our live deployment, with the exception of any
> _manually added_ files. There's a lot of cruft and I'm not sure yet
> which of the extra files are ancient one-offs and which we really need.
:)
We'll want to test a fresh checkout on test.wikipedia for a bit before
syncing live to all wikis.
-- brion vibber (brion @
wikimedia.org)
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This branch isn't where main development goes. Brion clearly laid
out that non-WMF people (ie me and most of the other volunteer
devs) shouldn't touch this branch. All main development continues
on trunk, I don't know why you'd think it would rot.
The main purpose of this branch is to provide a clearly visible snapshot
of what is running on the WMF cluster. This is never HEAD from trunk,
it's always a bit behind. Some critical bugfixes and hacks get pushed
in. Now we can all see when this happens, instead of just sysadmins.
I would imagine this new branch would be updated whenever A) code
has been reviewed and needs merging to WMF and B) whenever some
hotfix was put in place.
Some WMF hacks make it into trunk code because they're generally
helpful. Some do not.
-Chad
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l