On Mon, Feb 14, 2011 at 2:46 AM, Diederik van Liere dvanli...@gmail.com wrote:
So maybe we can paste these 5 steps (or something similar) in the initial
form used to file a bugreport.
This would increase the quality of bugreports and make it easier for bug
triaging.
Increase the quality
On Mon, Feb 14, 2011 at 12:15 AM, Brion Vibber br...@pobox.com wrote:
To start out with catching up on patch review, I took a look over and
applied the patches on bug 23817, fixing wfObjectToArray() and FormatJson
for a case that broke certain parts of ForeignAPIRepo when PHP's native JSON
2011/2/13 Ville Stadista ville.stadi...@gmail.com:
Currently, if you login on secure you are not logged-in on the
unencrypted site, even if I allow setting third party cookies in the
browser settings. I assume the login session is common to both
unencrypted and encrypted, so would it be
2011/2/13 Mark A. Hershberger mhershber...@wikimedia.org:
Right. And while I think your suggestion of assigning 7 developers a
day to do reviews could work, what if we divide the code into different
areas? From looking at the sub-directories under includes/ I would
suggest a different person
2011/2/13 MZMcBride z...@mzmcbride.com:
As I recall, it wasn't part of the first set of guinea pigs in case
something went horribly wrong and broke the site. Because mediawiki.org has
the code review tools, having mediawiki.org down when people are trying to
fix deployment problems would
2011/2/13 Bryan Tong Minh bryan.tongm...@gmail.com:
I agree... a bit. We should branch 1.18wmf1 immediately from trunk
once things have calmed down a bit. However, this 1.18wmf1 does not
necessarily need to be the base for 1.18. We can branch 1.18wmf2 from
trunk again and so on, until the time
I am not following this line of reasoning: how can adding guidance /
instructions on how to write a good bug report turn people away?
In a previous life, I have studied the factors that shorten the time
required to fix a big. Bugreports that contain steps to reproduce are a
significant predictor
If I am not mistaken then mercurial has better support for highly
modularized open source
software projects. You can use a mercurial subrepository (which is
very similar to svn external and git submodule). According to their
manual:
Subrepositories is a feature that allows you to treat a
2011/2/14 Diederik van Liere dvanli...@gmail.com:
I am not following this line of reasoning: how can adding guidance /
instructions on how to write a good bug report turn people away?
It's very simple, really: a form with a lot of fields may turn people
away. I know that it turns me away. How
Maybe i am not expressing myself clear, i am not talking about adding
checkboxes, radiobuttons or pulldown menus,
I am saying that we could add the following text to the textarea field
which contains the actual bugreport:
Please describe the steps to take to reproduce the problem:
What is the
On 14 February 2011 04:16, Daniel Friesen li...@nadir-seen-fire.com wrote:
Actually our users could be anyone who reads Wikipedia and notices
there's something wrong with what MediaWiki is doing or thinks there is
something about the ui we need to fix.
A few of these come into OTRS,
* Daniel Friesen li...@nadir-seen-fire.com [Sun, 13 Feb 2011 20:16:53
-0800]:
Actually our users could be anyone who reads Wikipedia and notices
there's something wrong with what MediaWiki is doing or thinks there
is
something about the ui we need to fix.
They don't even have to be as
On Sun, Feb 13, 2011 at 5:28 PM, MZMcBride z...@mzmcbride.com wrote:
Mark A. Hershberger wrote:
Perhaps we could recruit some people from the he.wikipedia.org community
to
take problems reported (via the localized interface?) and reproduce
them or
act as a translator between developers and
- Original Message -
From: Jeroen De Dauw jeroended...@gmail.com
+1 to migrate to a DVCS
Unless I'm mistaken no one has actually suggested doing that.
0 + 1 = 1, right? :-)
Cheers,
-- jra
___
Wikitech-l mailing list
2011/2/14 Mark A. Hershberger mhershber...@wikimedia.org:
If we have a 1.18 branch that is, as Brion has noted (and supported), a
day or two behind trunk at most, is there a reason that the we couldn't
branch wmfN from the rolling 1.18 branch? Or even just tag it when we
wanted to mark a WMF
phoebe ayers phoebe.w...@gmail.com writes:
Fascinating! I didn't know this existed either. To answer Mark's
question, I'm interested in facilitating more user participation in
bug-collecting. Using Bugzilla confuses the heck out of me, but mostly
because I don't do it very often!
Bugzilla is
On Mon, Feb 14, 2011 at 1:48 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
Bugzilla is a huge impediment to problem reporting for lay people. Even
technically trained ones, like myself, look at the UI and groan. I want
to do as much as possible to make problem reporting easier
On Feb 14, 2011, at 9:42 AM, Mark A. Hershberger wrote:
This is one reason I avoided suggesting that we switch to a DVCS for
1.18: The change is too big and dramatic and would impede too many
people's workflows without offering an immediate improvement.
Mark.
I'm not sure how much worse it
On Mon, Feb 14, 2011 at 2:18 AM, Siebrand Mazeland s.mazel...@xs4all.nl wrote:
With regards to i18n support it is not clear to me how translatewiki staff
would deal with 100+1 commits to different repo's every day if core and
extensions would each be in individual repos. Can you please explain
David Gerard wrote:
On 14 February 2011 17:40, Jay Ashworth j...@baylink.com wrote:
If you don't know what version you're using, the bug report will be next
to useless, particularly if it's fire and forget.
Any bug system has to capture everything possible, obviously.
Including private or
I was working on fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=27332
(resolved in r82155) and started messing with removing most of the gratuitous
lines in the search UI. Here's a screenshot of what we could do instead. I have
a patch for this that works in all browsers, including IE6.
phoebe ayers wrote:
There are many good ideas in this list. I have one small idea re:
bugzilla -- is it possible to make browsing bugs more transparent
(like a link on the sidebar)? I only just discovered that it's
possible to look at bugs by category, component or keyword rather than
search,
On Mon, Feb 14, 2011 at 8:01 PM, MZMcBride z...@mzmcbride.com wrote:
I don't think there's going to be any magical set of configuration changes
to make Bugzilla less horrible, but it's certainly worth a shot.
Neither do I, Bugzilla is always going to suck. Maybe we
can make it suck a little
I agree. I think that the search box needs to be distinct and obvious
as a control; this change blends it into the background too much.
Since search is one of our most important features, it should stand out
and be easier to target visually, not less.
On 2/14/11 6:27 PM,
On Mon, Feb 14, 2011 at 4:44 PM, Leo diebu...@gmail.com wrote:
One thing that bugged me a while:
Why does the bz robots.txt deny any bots? I think having it indexed by
google co would'nt exactly make searching harder.
Bugzilla actually ships with a default robots.txt that denies everything,
On Feb 11, 2011, at 8:36 AM, MZMcBride wrote:
Hi.
There are a few open bugs about adding mobile site support to a specific
Wikimedia wiki. For example, bug 27290 is about creating a mobile main page
for fa.m.wikipedia.org.[1]
What's the status of the mobile site / mobile site
On Tue, Feb 15, 2011 at 10:44 AM, Leo diebu...@gmail.com wrote:
One thing that bugged me a while:
Why does the bz robots.txt deny any bots? I think having it indexed by google
co would'nt exactly make searching harder.
Leo
Probably because historically you couldn't hide email addresses from
Thanks for your help, it indeed works.
From: wikitech-l-boun...@lists.wikimedia.org
[wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Platonides
[platoni...@gmail.com]
Sent: 09 February 2011 05:32
To: wikitech-l@lists.wikimedia.org
Subject: Re:
Hi,
I've found something strange in some files. The maximum ids for a page are:
latest
pages-articles.xml: 29189922
page.sql: 28707562
categorylinks.sql: 28705949
(15,684 categories and 135,521 articles are missing)
2011-01-15
pages-articles.xml: 30492297
29 matches
Mail list logo
