On Wednesday 21 December 2005 23:46, Brion Vibber wrote:
> Magnus, are you working with Tim on this or are you just writing code
> that's going to be thrown away next week?
Dear Brion,
I talked with Tim on this mailing list, where he said that stable
versions and their templates need to be cached, and that he worked on
some kind of patch.
I said OK, since you're working on that, I'll rest my extension.
A few days went by. As not much seemed to happen in this regard, I asked
if someone was working on it. I received no reply.
So I went ahed and did was had been discussed on my own, since noone
seems to do it.
And all I get as a reaction for, yet again, doing what everyone else
just keeps talking about is yor above comment.
This seems to be a pattern. Last year, I realized that we'd need a
review/validation feature, soon. So I went ahed and started implementing
one. I checked it into CVS and kept updating and improving it. Release
erly, release often, the open source mantra. I assumed that, this being
open source, and having 60+ developers listed at sourceforge for
MediaWiki, I would get some help in finishing it.
I didn't, not really. I wrote it up to working status basically on my
own, working in comments from test site users.
I checked in the first version seventeen month ago. SEVENTEEN MONTH! And
all the "help" I got was some vague uneasyness from you about it. At one
point you said something I could work with, namely that you were
concerned about it loading too much data from the database (or something
along that line), which I promptly fixed.
Then, I think it was two weeks ago, you said that, after seventeen month
of hot air, that the validation feature was unsalvagable. So I went
ahead and rewrote it as a feature, which was one of your wishes some
month ago. I have not heard anything about that from you either.
Don't take this as a personal attack. Maybe you're just overworked
(you've done a lot of work to be sure). Maybe you're suffering from a
mild case of Linus-Thorvalds-Syndrome, drowning in the responsibility
for the code. Or maybe you just don't like me; but then, I'm not the
only one to be treated like this, so it can't be that.
What *I* wish for is a process like this:
* Someone writes a major new function/extension to be used on the
Wikimedia sites
* Someone in charge of these sites (Tim, Brion, whoever) says either
** "OK, that's great, we'll use it right away" OR
** "No, we'll never use that, so don't waste your time" OR
** "We would use it if you fix THIS and change THAT"
I once was an author at Nupedia. The approval process was so slow that
few people ever wrote there, let alone got an article through the review
process. A few of my articles made it afer three to four month. It was a
drag, but my article was in the "official" list at the end.
But being largely ignored for SEVENTEEN MONTH, writing code and pushing
for it to be used, and then being told "nope" would make paid
programmers leave a company. I'm sure that, if not you youself, at least
others on this mailing list might imagine what that kind of treatment
can do for the motivation of a volunteer developer.
So, to come back to the original topic, this is *the* chance to answer a
few of my questions:
* Is /anyone/ actively working on a stable version feature?
* If so, is it already more advanced than the code I put into CVS?
* Is there some other reason this can't be done based on my code?
As I have said many times before, I'm not pushing these things because
they are /my/ code. I'm pushing them because IMHO we need them, and
AFAIK my code is the only one currently available that is up to the job.
If I am in error on one of these two, please tell me so, and do it in
clear, simple words, as I see myself unable to convert musings of vague
discomfort into code changes.
Also, again, I have no problem if you think my code is crap. That might
well be the case. *All I want* is that you tell me
* what the problems are
* if Wikimedia would use the code if I were to fix those problems, or if
I shouldn't bother
I'll be on the 22C3, so maybe we could discuss these things in person.
Magnus
I updated that page.
- because MediaWiki is now at version 1.5.3, and
- has email notification built-in (even when this is still disabled on
the major project sites).
T.
I've gone ahead and committed the new page protection UI. This allows seeing
exactly what a page is set to, and logs a bit more information; so no more "hey,
is this page really protected or just protected against moves?".
It's a bit more complex, but hopefully not too scary.
Additionally there's a new level between unprotected/default permissions and
sysop-only; this is set up on en.wikipedia.org and will restrict edits by
unregistered users and accounts less than four days old.
(This is to implement http://en.wikipedia.org/wiki/WP:SEMI )
There's now a timestamp field on the user table for the registration date, which
is used to calculate the age (this'll be included on newly registered accounts
but is NULL on older ones).
The age setting replaces the percentage formerly used for the sitewide move
limitations.
-- brion vibber (brion @ pobox.com)
The new Review extension, which replaces the Validation feature, can be
seen in all its overwhelming beauty at
http://magnusmanske.de/wikipeerdia/index.php
That site also features the Tasks extension.
Magnus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Boris Herbinière-Sève wrote:
> I guess the best way to integrate this into mediawiki is through a
> special page, but I was unable to find any useful doc (whereas help
> for extensions on meta-wiki is really useful. Thanks).
Hi, I'm assuming the metawiki page you are referring to is
[[meta:Writing a new special page]] and that you know how to integrate a
special page to the system.
I recommend reading the API documentation (
http://wikipedia.sourceforge.net/doc/ ) or actually going through the
source code and finding out how the core code goes about doing the job.
Boris Herbinière-Sève wrote:
> I need a custom page with access to another DB, SQL requests and
> processing.
If the DB is not the same as the one MediaWiki is using, you will likely
have to implement your own infrastructure. From what it seems to me, the
current DB classes are not easily reusable. I may be wrong though.
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDq0KKqTO+fYacSNoRAlglAJ9sQ9B0U9WCEM8JlayUsNercJRYtACeJd4I
BF02VDzT1mXnGY00WuJ/wPU=
=w02N
-----END PGP SIGNATURE-----
There currently is a problem with the new Protection UI, which disabled the
precautionary move-protection that was installed on HEAD.
Currently, new pages are created with an empty protection string. To fix it,
all the pages that have that empty string have to be changed to
[move=autoconfirmed] through a conversion script. [move=autoconfirmed] also
needs to be the default string when creating a new page.
Pages with a non-empty protection string should be working properly.
Titoxd
Brion et al.,
I'm through my to-do list for the namespace changes. They reside in the
WIKIDATA branch.
a) Please review these changes and point out any remaining issues that
need to be addressed.
b) Which branch should these changes be merged into once fully reviewed?
HEAD or a separate release branch?
Best,
Erik
= The changes in a nutshell =
== Backend ==
- All namespace definitions are stored in the database (cached using
memcached if available). Namespaces are objects stored in a global
array, $wgNamespaces, and generally easier to deal with.
- Any namespace can have an arbitrary number of names. This includes the
canonical English name, the local translation, and synonyms.
- Every namespace has a default name to which all other names redirect.
- By default, "Image:" is now accessible through File:, Image:, Video:
and Sound:.
- Namespaces can have a default link prefix. Every unprefixed link in
those namespaces will be treated as if it was prefixed with it. Example:
In namespace [[Cookbook:Fish]], [[Pig]] could become [[Cookbook:Pig]].
The edit page in the namespace contains a notice to this effect.
- Namespaces can be hidden from most selection lists, to make managing a
site with hundreds of namespaces feasible.
- The relationship between namespaces and talk pages is no longer
hardcoded. Theoretically, we can relatively easily implement support for
multiple talk pages associated with a namespace, for example.
== Namespace manager ==
- All the attributes of namespaces which are changeable can be changed
through the namespace manager ([[Special:Namespaces]]).
- The namespace manager allows merging "pseudonamespaces" into real
ones. For example, Wikibooks uses a prefix "Cookbook:" for its Cookbook
pages; the namespace manager provides a facility for merging all pages
with this prefix, as well as the talk pages, into a real namespace.
- By default, users in the 'bureaucrat' group have the necessary rights.
We take some reasonable security precautions:
- Deletions are not possible if a namespace contains pages.
- System namespaces expected by MediaWiki can never be deleted.
- Additions that would hide "pseudonamespaces" (hardcoded prefixes in
page titles) or Interwiki links are not possible.
- A separate permission exists for merging pseudonamespaces into
non-empty real ones, since this action can be essentially
irreversible.
- It should not be possible to make changes which leave the database
in an inconsistent or illogical state. No operation is performed
unless all its parts can be completed.
- Namespace additions, deletions, conversions and changes are logged.
The logging of namespace changes could be improved, but should be
sufficient for now.
== Install and Upgrade process ==
- When installing MediaWiki for the first time, the namespace
definitions are loaded in the appropriate language.
- When upgrading MediaWiki using update.php, any existing custom
nanemspace definitions and settings (subpages etc.) should be imported.
== Page titles ==
- The page title is now passed to the skin in its components (action,
namespace, title, suffix) rather than as a single string. These can be
styled differently. In MonoBook, for example, the namespace component is
now smaller and in italics.
- This has resulted in some simplified interface messages.
== Future features ==
Some ideas for things that could be implemented:
- Read/write permissions associated with namespaces.
- Namespace icons that are rendered as part of the page tite.
- Complex namespace hierarchies.
- Default "preload" template for a namespace.
- Namespace view filters for users. This could make it feasible to use a
single installation to set up a wiki farm.
- And, of course, association of namespaces with Wikidata schemas. :-)
What does this mean:
Warning: mysql_query(): 81 is not a valid MySQL-Link resource in
/home/includes/Database.php on line 374
Unable to free MySQL result
Any Hints?