Tim Starling <tstarling(a)wikimedia.org> writes: There were several other bugs that were duplicates of it. Including, most recently, https://bugzilla.wikimedia.org/27906. Developers keep running into it. But you're right that it probably doesn't rise to the level of “highest” priority. It should be included as a point of reference for the work on the parser that is being done and, for that reason, it is tagged “parser”. I've changed the priority. Mark.

On Tue, Mar 15, 2011 at 04:32, Ashar Voultoiz <hashar+wmf(a)free.fr> wrote: How do you get such a list from bugzilla? Helder

On Tue, Mar 15, 2011 at 3:00 PM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote: Like so: http://bit.ly/hRKxXz

On March, 15 2011, at 23:23 Helder wrote: Here's a variation ordered by number of votes and and filtered out (and speed up the query) all bugs with 1 or no votes at all: http://bit.ly/wmbugstopvotes -- Krinkle

Voting is disappearing with the BZ4 upgrade anyway. -Chad On Mar 15, 2011 4:40 PM, "K. Peachey" <p858snake(a)yahoo.com.au> wrote: wrote:

Hoi, When voting for bugs is relevant, it is quite feasible to promote voting again. As it is, votes are not considered so at one stage I actively discouraged voting. I will be really pleased to talk up voting for bugs when votes are factored in in the the decision what to do next. It helps when a guestimation is added to the amount of work involved. Voting for something small gets easier done *and finished* then something like re write the parser. Thanks, GerardM On 17 March 2011 08:30, Ashar Voultoiz <hashar+wmf(a)free.fr> wrote:

Ashar Voultoiz <hashar+wmf(a)free.fr> writes: The bugmeister does look at the votes field, though. I'm going to see what we can do to get (or something like it) included in the upgrade to Bugzilla. Developers probably don't need to worry about it, though. Mark.

Ashar Voultoiz <hashar+wmf(a)free.fr> writes: Thanks. Of course, I hope we can still get a 1.17 tarball together in a timely manner. Decisions, decisions. Excellent idea! Here are the 11 open enhancement requests that got more than 30 votes. Votes Summary 116 Support collation by a certain locale (sorting order of characters) http://bugzilla.wikimedia.org/164 83 Interproject links http://bugzilla.wikimedia.org/708 61 Interwikies sort in phonetic, site defined order http://bugzilla.wikimedia.org/2867 46 Automatic category redirects http://bugzilla.wikimedia.org/3311 45 Use a dedicated interface for adding interwiki/category links, not wikitext http://bugzilla.wikimedia.org/167 44 Allow users to be blocked from editing a specific article http://bugzilla.wikimedia.org/674 43 Add a music wikimodule http://bugzilla.wikimedia.org/189 42 gallery of images uploaded by a user http://bugzilla.wikimedia.org/3341 40 Add section edit link for 0th section http://bugzilla.wikimedia.org/156 33 Implement the Interlanguage extension in Wikipedia http://bugzilla.wikimedia.org/15607 31 Enable template inclusion from Commons (transclusion => interwiki templates, etc.) http://bugzilla.wikimedia.org/4547 Some of these are being worked on (#4547, #15607), some have patches that, if outdated, at least act as a place-holder of someone's idea for how things should be done (#3341, #674, #3311, #2867, #164). All of them, though, are visible changes that developers haven't (yet) rejected with WONTFIX, but, despite the interest, no one has managed to take care of yet. Each of these bugs tells a story. Each one reflects a strong desire. Each one is a chance for a new star to be born. (Forgive my melodrama, but the interest shown on these bugs feels pretty compelling to me.) Mark.

On 03/16/2011 02:05 AM, Mark A. Hershberger wrote: I'd say it's done.

Mark A. Hershberger wrote: There are a few bugs that aren't really "shell" bugs, but actually "root" bugs (which doesn't have its own keyword). I think it'd be nice to include one "root" bug every week. For example, I'm fairly sure <https://bugzilla.wikimedia.org/show_bug.cgi?id=9204> is ready to be deployed across the cluster, but requires a root user. I don't remember off-hand if creating a wiki is something that a normal "shell" user can do, so those might be an option for "root" bugs as well. Just a thought. MZMcBride

On Wed, Mar 16, 2011 at 11:38 AM, Roan Kattouw &lt;roan.kattouw(a)gmail.com&gt; wrote: Why is a rootuser needed for changing DNS entries? A zonefile is a normal textfile, after all - and if you use PowerDNS on one server configured as supermaster with a MySQL backend and other servers with PowerDNS as superslave (backend is not important there), you don't even need shell access to manage your DNS. Not even for creating new zones, as the supermaster makes all slaves automatically sync those zones where the invidual slaveserver is listed with a NS entry. </powerdns_ad> Marco

Roan Kattouw wrote: There's no need for both steps to be done at the same time. An ops person could add the dns entry and have the real wiki be added later.

Aryeh Gregor wrote: It does send an error listing a project index, if you try to use a non-existant project.

On Fri, Mar 18, 2011 at 11:39 AM, Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com&gt; wrote: I think he means for ones that have the DNS zone but not the wiki created.

On Thu, Mar 17, 2011 at 11:40 PM, Tim Starling &lt;tstarling(a)wikimedia.org&gt;wrote;wrote: Given that the pushing out of DNS updates is already scripted up, I worry about keeping the need to go grab someone and get them to add a line to a file and run the command. No it isn't much work in literal terms, but there's a surprisingly big gulf between "thing you can do yourself in 2 minutes" and "thing you can mostly do yourself in 2 minutes, but you'll have to track down someone else to do 30 more seconds for you, make sure they understand what you're asking for, see if they agree, and hope they have the time and inclination to actually do it". What I'd like to see is that the people who are actually approving new wiki creations should be able to actually make a wiki creation happen immediately. Most of the configuration settings *should* be things that can be set at creation time or afterwards, through a web interface, by those same people or stewards, bypassing the need to bottleneck decision->implementation through system administrators. Forcing all this stuff to be done by a small number of server admins and developers hand-editing configuration files in a terminal isn't a good use of peoples' time. The actual config editing is awkward and error-prone, and the need to communicate, verify, and authenticate requests slows things down and keeps power out of peoples' own hands. -- brion