It is a generic problem, but it has particularly nasty interactions with
RevisionDelete: fundamentally, it can become impossible to tell when, why or
by whom a RevDel'd revision was deleted. The other manifestations of the
lunacy of identifying deleted revisions by timestamp rather than revision id
are not so serious, but these definitely are.
Identifying deleted revisions by id rather than timestamp is a lot of work
in itself; not least of which is writing and running a script to fill in all
the null values for old deleted revisions on WMF wikis. There's no point in
doing that if the 'grand plan' is to move away from having an archive table
altogether. But equally this is an issue which does badly need work done.
Hence the question, ""what *is* the grand plan?""
--HM
--------------------------------------------------
From: "Andrew Garrett" <andrew(a)werdn.us>
Sent: Tuesday, May 18, 2010 3:05 PM
To: "Happy-melon" <happy-melon(a)live.com>; "Wikimedia developers"
<wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Deletion schema
> On Tue, May 18, 2010 at 8:24 AM, Happy-melon <happy-melon(a)live.com> wrote:
>> There's another discussion happening at enwiki at the moment about the
>> stalled rollout of RevisionDelete for admins; which is backed up in the
>> chain of bugs which boils down to "our deletion mechanism is borked".
>>
>> Reviewing the whole deletion mechanism was on the topic list for the last
>> dev meetup, but AFAIK despite that event running for three times as long
>> as
>> it was expected to, it never got raised? I think this would be as good a
>> time as any to do so. Do we have any clear idea or overall plan for page
>> and revision deletion, the archive table, a page_deleted field, a
>> deleted_page table, etc etc??
>
> I promised to activate single-revision deletion for admins months ago,
> and then again after the last software update. I finally got to it
> tonight.
>
> Church of Emacs points out this bug, but it looked as though it was a
> generic problem with our previous deletion system, and not an
> additional problem caused by single-revision deletion (indeed, it
> appears to be mitigated by the use of single-revision deletion instead
> of the old delete/undelete method).
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=21279
>
> --
> Andrew Garrett
> http://werdn.us/
>
Hi all;
Solving captcha during registration is mandatory. Can this be replaced with
a sound captcha for visual impairment people? It is a suggestion to the
usability project too. Thanks.
Regards,
emijrp
There's another discussion happening at enwiki at the moment about the
stalled rollout of RevisionDelete for admins; which is backed up in the
chain of bugs which boils down to "our deletion mechanism is borked".
Reviewing the whole deletion mechanism was on the topic list for the last
dev meetup, but AFAIK despite that event running for three times as long as
it was expected to, it never got raised? I think this would be as good a
time as any to do so. Do we have any clear idea or overall plan for page
and revision deletion, the archive table, a page_deleted field, a
deleted_page table, etc etc??
--HM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
How can I configure Mobile Skin?
Mobile Skin is only one?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)
iD8DBQFL7dvrZZnabYK3t6gRAlDFAJsHwG+ra6duJ6IuLr1ZF4BFctDb0wCeJFx3
OMqd8Dn4oXHFMlACs7ySFWA=
=h4oe
-----END PGP SIGNATURE-----
How large would the projects' image bundles be uncompressed, if they
were to exist?
Also asked at:
http://meta.wikimedia.org/wiki/Talk:Data_dumps#How_big_would_image_bundles_…
However, someone suggested I should be on wikitech-l more, so I
thought I would try asking here. I read here regularly, but I prefer
the dogfood. I promise to send the answer to the other place the
question was asked if someone else doesn't do so first.
This is for a mirror project, which I want to fork into a peer-to-peer
wiki system. A serious problem with peer-to-peer wikis is edit
conflict resolution -- most everything else about syncing is not as
hard as that in general. People often make the mistake of using git
as a metaphor, but code merges are much more tightly coupled with the
text being edited than most Foundation projects. But edit conflict
resolution is so hard in peer-to-peer mode; for example, the two
editors in conflict may be unavailable, and the person faced with the
conflict may not understand the original or either of the two edited
versions. We can use croudsourcing systems to, for example, have three
people try to resolve each nontrivial conflict, and three more people
to decide which of the first three was best; if there isn't
substantial agreement, get a fourth proposal in light of the first
three, etc. Can anyone think of a way to motivate volunteers to
resolve edit conflicts as a third party?
Sincerely,
James Salsman
Dear all,
I would like to develope a simple extension: add a tag named MyTag, it should be like this:
<MyTag> Contents...
</MyTag>
For the contents use inputs, I want to use the system default parser to parse the text, E.g. a table, a title and so on...
For MyTag tag, I only want to add a div container.
For example:
User input:
<MyTag>
{|
|Orange
|Apple
|-
|Bread
|Pie
|-
|Butter
|Ice cream
|}
</MyTag>
Then system display article like this (div is a html element, can not display on the screen)
<div>
OrangeApple
BreadPie
ButterIce cream
</div>
can anyone help me? thanks in advanced!
2010-05-16
muiz
Good morning,
I'm planning some downtime for Bugzilla this weekend on Saturday
(I'll update later once I decide an actual time). There's quite a bit of
cleanup that needs to be done and I'm going to shut down BZ for
the duration so I don't send out a few thousand e-mails and spam
everyone's inboxes. Here's the primary list of things I plan to do:
- Remove deprecated keywords (fixed-in-cvs, etc)
- Remove keywords that aren't applicable (needs-review on closed bugs)
- Kill deprecated products (Issues, Logwood too? I think those can be
moved to Wikimedia -> Usage/Statistics)
- Consolidate version numbers (1.3.1, 1.3.2, etc to 1.3.x, for all non-recent
versions)
If anyone else can think of other things to do while we're at it please
feel free to take a look at [[mw:Bugzilla cleanup]].
Thanks,
Chad