On 8/30/07, brion@svn.wikimedia.org brion@svn.wikimedia.org wrote:
Adds what seems to be a very purpose-specific extension into the core API:
It's not that purpose-specific.. the name in the code should perhaps be changed. The purpose is to be able to declare a site as a remote repository and have it work in the same way Commons does in the WMF environment.
There were some issues with the code that Paa Kwesi committed, and I've asked him to fix those.
a) shortly before release
Perhaps it would be wiser to simply not include it in the release branch if that is a problem?
b) while apparently not implementing much of its interface c) with an interface that looks kind of strange to me
Could you be more specific here and make a list of things that you think should be done before this can be in trunk?
On 31/08/2007, Erik Moeller erik@wikimedia.org wrote:
There were some issues with the code that Paa Kwesi committed, and I've asked him to fix those.
Why wasn't this worked on in the branch beforehand? If it's in a branch in our repository, there are the benefits of ongoing peer review (because everyone who gets a commit notification is likely to glance at it, at least), it makes merging things easier when the time comes, etc.
a) shortly before release
Perhaps it would be wiser to simply not include it in the release branch if that is a problem?
This requires additional fiddling, and means the release branch isn't a pure branch in the classic sense. It creates more work for the release manager, and sets an odd precedent.
Rob Church
On 8/31/07, Erik Moeller erik@wikimedia.org wrote:
a) shortly before release
Perhaps it would be wiser to simply not include it in the release branch if that is a problem?
Perhaps it would be better to branch earlier so things don't get reverted solely for the reason of being shortly before release. People could commit non-major changes to both branch and trunk, and relatively major/untested things to trunk only (or, if they're lazy, everything to trunk only). Usually we only have a branch up for a few days, but revert things on the basis of being before a release for a couple of weeks beforehand at least, and in the last one or two cases for over a month beforehand.
But of course, our release manager has way too much to do already.
On 31/08/2007, Simetrical Simetrical+wikilist@gmail.com wrote:
Perhaps it would be better to branch earlier so things don't get reverted solely for the reason of being shortly before release. People could commit non-major changes to both branch and trunk, and relatively major/untested things to trunk only (or, if they're lazy, everything to trunk only). Usually we only have a branch up for a few days, but revert things on the basis of being before a release for a couple of weeks beforehand at least, and in the last one or two cases for over a month beforehand.
This would certainly be something to consider, given that I don't anticipate the overall workload for those involved reducing in future around Wikimania time, and given that Wikimania is likely to always be held at times which coincide with a release.
I'd discourage actually allowing people without sufficient experience (and personally, I wouldn't, full stop) from merging to the release branch without the direct permission of the release manager, simply because silly little things do slip through, and break stuff.
But of course, our release manager has way too much to do already.
I dare say it's no hardship to create a branch in advance, especially if it cuts down or eases the later workload.
Rob Church
On 8/31/07, Rob Church robchur@gmail.com wrote:
I'd discourage actually allowing people without sufficient experience (and personally, I wouldn't, full stop) from merging to the release branch without the direct permission of the release manager, simply because silly little things do slip through, and break stuff.
Our release manager happens to also be our lead developer (at least for now), so he's reviewing all commits anyway. But either way.
Erik Moeller wrote:
On 8/30/07, brion@svn.wikimedia.org brion@svn.wikimedia.org wrote:
Adds what seems to be a very purpose-specific extension into the core API:
It's not that purpose-specific.. the name in the code should perhaps be changed. The purpose is to be able to declare a site as a remote repository and have it work in the same way Commons does in the WMF environment.
That's all very well, but it will be rather useless until there is also a client side. All the instantcommons API module does at the moment is dumps all the string properties of an Image object loaded by name.
At the minimum there needs to be a way for servers to specify whether or not they give their consent for their image repository to be used as a remote repository in a foreign MediaWiki installation. A generic image properties API would be fine in the core (if it was properly implemented), but the InstantCommons client most certainly couldn't use it without this permissions element.
I've moved it to an extension, it's at extensions/InstantCommons.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling wrote:
Erik Moeller wrote:
On 8/30/07, brion@svn.wikimedia.org brion@svn.wikimedia.org wrote:
Adds what seems to be a very purpose-specific extension into the core API:
It's not that purpose-specific.. the name in the code should perhaps be changed. The purpose is to be able to declare a site as a remote repository and have it work in the same way Commons does in the WMF environment.
That's all very well, but it will be rather useless until there is also a client side. All the instantcommons API module does at the moment is dumps all the string properties of an Image object loaded by name.
Which should already be present in the API, so why add a second one?
What really confused me was the example URLs it lists which do things like 'delete' and 'update' .... this doesn't seem to make any clear sense in either a server or client-side API, and they're not implemented either, so they *definitely* don't belong on trunk.
Remember that trunk is supposed to be *live code* -- keeping things up to date and ready to run at all times is our biggest method of quality control. Code *must work* at all times, expect of course when it's broken by accident. :)
At the minimum there needs to be a way for servers to specify whether or not they give their consent for their image repository to be used as a remote repository in a foreign MediaWiki installation. A generic image properties API would be fine in the core (if it was properly implemented), but the InstantCommons client most certainly couldn't use it without this permissions element.
I've moved it to an extension, it's at extensions/InstantCommons.
Thanks.
- -- brion vibber (brion @ wikimedia.org)
wikitech-l@lists.wikimedia.org