Happy Monday!
We did it. https://phabricator.wikimedia.org now contains all the Bugzilla
reports. If you need to check the original Bugzilla, it can be found at
https://old-bugzilla-wikimedia.org (never mind the certificate warning, it
will go away today or so).
Important notes:
* If your Bugzilla activity still hasn't been assigned to you, just
wait. bzimport is processing the data of about 800 users. It assigns tasks
first, then comments. Don't be surprised if you see a task assigned to you,
while your comments still belong to bzimport.
* Another ongoing background task: after injecting 73k tasks, it is
possible that not all the content is indexed yet, so some search results
might still be missing.
* Join and watch the projects that matter to you. We have almost 700
new projects imported that nobody is watching currently. This is especially
relevant if you were "default CC" in Bugzilla components. Details:
https://www.mediawiki.org/wiki/Phabricator/Help#Receiving_updates_and_notif…
and https://phabricator.wikimedia.org/T75699
* Do not change project names and policies for now. You may break links
in Phabricator and mediawiki.org. See
https://www.mediawiki.org/wiki/Phabricator/Requesting_a_new_project#Guideli…
* Bugzilla URLs redirect to Phabricator (most of them) or old-bugzilla
(some). Details:
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Redirected_URLs_…
If you find bugs, please report them under the "Phabricator" project. If
you need support, ask in #wikimedia-devtools.
As usual, all the relevant details can be found at
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla
BIG THANK YOU to everybody involved in this big, long, and complex
migration. It has been really exciting to deploy a Phabricator instance
with 75k tasks, the biggest Maniphest container we are aware of.
And well, this is only the beginning. Right now we will focus in the most
urgent post-Bugzilla-migration tasks, while starting to prepare the RT
migration. Your tasks, comments, and tokens are welcome. Check the current
backlog at https://phabricator.wikimedia.org/maniphest/query/y2CdmZwKv3oZ/#R
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
I have published a draft RFC about testing MediaWiki core and the
extensions all together in a single job. As a first step limited to the
extensions deployed on the Wikimedia cluster.
That would let us catch tricky dependencies such as an incompatible
change in Mantle breaking Flow and MobileFrontend. Currently, a change
made to Mantle does not run the tests of other extensions depending on
it. The RFC aims to solve it
>From the RFC:
We will first present how Zuul establish states of repositories for a
given patchset, then the utility that makes it trivial to reproduce such
a state on a Jenkins slave taking for example the mediawiki/core and
mediawiki/vendor tight integration that is being used today. Finally we
will propose to extend such system to all MediaWiki extensions deployed
on the Wikimedia cluster.
The link:
https://www.mediawiki.org/wiki/RFC/Extensions_continuous_integration
--
Antoine "hashar" Musso
Hi!
There is now a Special:SkinDistributor[1] on mediawiki.org that will
allow you to download tarballs of skins that are hosted on gerrit. Since
skins have moved out of the core repository and handled like extensions
as of 1.24, it's now possible to provide an easier way to download them.
In addition, I discovered that the tarball generator (for both
extensions and skins) was including .git subdirectories in the tarballs
it was creating, causing extremely large tarballs depending on the
history. It no longer does that[2], shrinking tarballs by over 100MB in
some cases!
Thanks to Chad and Yuvi for helping with code review and the deployment!
-- Legoktm
[1] https://www.mediawiki.org/wiki/Special:SkinDistributor
[2] https://gerrit.wikimedia.org/r/#/c/174777/
Hi,
In Bugzilla some projects used prefixes in bug titles. I guess that it was
done to make sure that people understand to what project does the bug
pertain as quickly as possible. The one that I ran into most frequently is
"VisualEditor:", and there may be others.
In Phab I see that bug (task?) lists and search results always have a
project (briefcase) tag near them. If these tags indeed appear every time
the bug title is shown, then the prefixes are redundant.
Does any object to start removing them?
(Also, I don't remember that "Phab" was ever declared as an official
abbreviation of "Phabricator", and I like it when such things are declared.
So here, I declare that "Phab" is an abbreviation of "Phabricator". Please
protest if you disagree.)
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
> On Sun, 23 Nov 2014, at 19:25, Anthony Cole wrote:
>> On Wed Nov 12 01:05:26 UTC 2014 I asked this list if the technical team
>> could help the patrollers of recent changes to Wikipedia's medical articles
>> “...tag the log entry of revisions ... as having been reviewed for
>> policy/guideline compliance by a trusted editor.” [1]
>>
>> I am quite technically illiterate and may have misunderstood, but judging
>> by Yusuke Matsubara's description, the extension he mentions above seems
>> like it might fit our needs. Will it enable patrollers to add a comment to
>> the edit summary? Does anyone know if it works on en.Wikipedia?
>>
>> 1.https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079418.html
I don't think it is promising to use the RevisionCommentSupplement
extension for a kind of revision tagging in the manner described. For
example, the extension doesn't have the functionality of filtering
RecentChanges by appended summaries. The intended use case is
re-explain the individual edit so that humans (readers) can better
understand it.
A more promising approach might be (re-)using "tags" [1] - AbuseFilter
and a few other tools (such as HHVM) add tags to revisions, and
RecentChanges can (already) be filtered by tags. Is there an
implementation that allows editors with certain privilege to
add/remove a certain tag to a chosen revision? Is it easy to create
one?
[1] https://www.mediawiki.org/wiki/Manual:Tags
Best,
Yusuke
On Sun, Nov 23, 2014 at 7:15 PM, svetlana <svetlana(a)fastmail.com.au> wrote:
> - I think this ML top-posts. Not sure.
> - Suspect that the Flow extension would allow for more flexibility, including attaching multiple discussion threads to a specific edit or paragraph.
>
> --
> svetlana
>
> On Sun, 23 Nov 2014, at 19:25, Anthony Cole wrote:
>> (Sorry, I posted this in the wrong thread a few minutes ago.)
>>
>> On Thu, Nov 13, 2014 at 9:57 PM, Yusuke Matsubara <whym at whym.org
>> <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>> wrote:
>> >** On Thu, Nov 13, 2014 at 9:15 PM, Amir E. Aharoni
>> **>* <amir.aharoni at mail.huji.ac.il
>> <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>> wrote:
>> *>>* I tried looking for it in Bugzilla; I expected to find a two-digit bug for
>> *>>* it, but I couldn't find any at all. Of course it's possible that I didn't
>> *>>* look well enough.
>> *>>* A bit different, but there is an extension that enables
>> *>* "supplementing" additional non-modifiable edit summaries:
>> *>* https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement
>> <https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement>
>> *>>* It was contributed (without a Bugzilla request) by Burthsceh, a
>> *>* volunteer at Japanese Wikipedia, prompted by the necessity to fix
>> *>* attributions made in edit summaries (for reused texts). [1] I don't
>> *>* think it has been extensively reviewed, though.
>> *>>* With that approach, you could effectively modify an edit summary by
>> *>* appending a modified one and rev-deleting the original one.
>> *>>* [1] https://ja.wikipedia.org/wiki/Wikipedia:%E4%BA%95%E6%88%B8%E7%AB%AF/subj/%E…
>> <https://ja.wikipedia.org/wiki/Wikipedia:%E4%BA%95%E6%88%B8%E7%AB%AF/subj/%E…>
>> *
>>
>>
>> On Wed Nov 12 01:05:26 UTC 2014 I asked this list if the technical team
>> could help the patrollers of recent changes to Wikipedia's medical articles
>> “...tag the log entry of revisions ... as having been reviewed for
>> policy/guideline compliance by a trusted editor.” [1]
>>
>> I am quite technically illiterate and may have misunderstood, but judging
>> by Yusuke Matsubara's description, the extension he mentions above seems
>> like it might fit our needs. Will it enable patrollers to add a comment to
>> the edit summary? Does anyone know if it works on en.Wikipedia?
>>
>> 1.https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079418.html
>>
>>
>> Anthony Cole <http://en.wikipedia.org/wiki/User_talk:Anthonyhcole>
>> _______________________________________________
>> 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
- I think this ML top-posts. Not sure.
- Suspect that the Flow extension would allow for more flexibility, including attaching multiple discussion threads to a specific edit or paragraph.
--
svetlana
On Sun, 23 Nov 2014, at 19:25, Anthony Cole wrote:
> (Sorry, I posted this in the wrong thread a few minutes ago.)
>
> On Thu, Nov 13, 2014 at 9:57 PM, Yusuke Matsubara <whym at whym.org
> <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>> wrote:
> >** On Thu, Nov 13, 2014 at 9:15 PM, Amir E. Aharoni
> **>* <amir.aharoni at mail.huji.ac.il
> <https://lists.wikimedia.org/mailman/listinfo/wikitech-l>> wrote:
> *>>* I tried looking for it in Bugzilla; I expected to find a two-digit bug for
> *>>* it, but I couldn't find any at all. Of course it's possible that I didn't
> *>>* look well enough.
> *>>* A bit different, but there is an extension that enables
> *>* "supplementing" additional non-modifiable edit summaries:
> *>* https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement
> <https://www.mediawiki.org/wiki/Extension:RevisionCommentSupplement>
> *>>* It was contributed (without a Bugzilla request) by Burthsceh, a
> *>* volunteer at Japanese Wikipedia, prompted by the necessity to fix
> *>* attributions made in edit summaries (for reused texts). [1] I don't
> *>* think it has been extensively reviewed, though.
> *>>* With that approach, you could effectively modify an edit summary by
> *>* appending a modified one and rev-deleting the original one.
> *>>* [1] https://ja.wikipedia.org/wiki/Wikipedia:%E4%BA%95%E6%88%B8%E7%AB%AF/subj/%E…
> <https://ja.wikipedia.org/wiki/Wikipedia:%E4%BA%95%E6%88%B8%E7%AB%AF/subj/%E…>
> *
>
>
> On Wed Nov 12 01:05:26 UTC 2014 I asked this list if the technical team
> could help the patrollers of recent changes to Wikipedia's medical articles
> “...tag the log entry of revisions ... as having been reviewed for
> policy/guideline compliance by a trusted editor.” [1]
>
> I am quite technically illiterate and may have misunderstood, but judging
> by Yusuke Matsubara's description, the extension he mentions above seems
> like it might fit our needs. Will it enable patrollers to add a comment to
> the edit summary? Does anyone know if it works on en.Wikipedia?
>
> 1.https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079418.html
>
>
> Anthony Cole <http://en.wikipedia.org/wiki/User_talk:Anthonyhcole>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
In Facebook it's possible to edit posts and comments after posting after a
lot of users asked for it.
Why isn't it possible to change MediaWiki edit summaries after posting?
I tried looking for it in Bugzilla; I expected to find a two-digit bug for
it, but I couldn't find any at all. Of course it's possible that I didn't
look well enough.
https://en.wikipedia.org/wiki/Help:Edit_summary just says that they can't
be changed, but doesn't link to a discussion.
So is there any reason not to do it?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
We are polishing the last details before starting the Bugzilla migration to
Phabricator on 21 November at 00:30 UTC.
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141121T0030
You can find all the details of what will happen next in the timeline at
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla
MIGRATION WEEKEND
Basically, Bugzilla access will be restricted to read-only, Phabricator
will be pulled, and we will start the migration. If all goes well, by
Monday 24 Phabricator will be back with about 75k tasks, and Bugzilla will
be archived in old-bugzilla.wikimedia.org.
During this period, we will redirect users to a page asking them to
postpone their bug reporting unless it is so urgent that it cannot wait
until Monday. In that case, they can use #wikimedia-bug2phab on IRC and
mediawiki.org's Support Desk.
If you registered in https://phabricator.wikimedia.org before the
migration, your Bugzilla activity will be probably assigned to you by the
time you check the site. Otherwise, you will still be able to register and
claim your activity, which will be assigned to you within a couple of hours
or a couple of days, depending of the queue.
KNOWN ISSUES
We are confident about the stability of Phabricator and also about the
reliability of the migration process. However, there are several known
issues related with data and features that will be missing next Monday.
We cannot assign to Phabricator tasks the same number as their Bugzilla
equivalents. Instead, automatic redirects will link old Bugzilla URLs with
their corresponding new Phabricator tasks. phabricator.wikimedia.org has
already >1300 tasks with numbers taken. The migration needs to be done by
batches of bugs instead of sequentially, which makes the mapping of numbers
more complicated. Still, smaller numbers will correspond to older bugs, and
we will do our best during the weekend to improve the sorting.
Votes and saved searches cannot be migrated. Users willing to have their
equivalent in Phabricator (tokens a new saved searches) will be able to
access their accounts in old-bugzilla.
A feature that we expect to be missed is suggestions for duplicates when
creating a new task. Even if Phabricator's search is powered by
Elasticsearch, we feel like it needs some fine-tuning to get to Bugzilla's
efficiency. Advanced Bugzilla users will also find that some actions take
more clicks (assigning blocker/blocking tasks, for instance). In general,
most fluent Bugzilla users new to Phabricator will need a few days to get
used to how things work in Phabricator.
There is a complete list of known issues at
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Known_issues --
and we will keep working on them after next Monday.
IMPROVEMENTS
We expect that the improvements will make the change worth right after the
migration, of course. A simpler and cleaner UI that works on mobile,
Wikimedia SUL, bugs and features living together, ability to associate
tasks to several projects, workboards, and many more features are waiting
for you! :)
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil