Since I've had so much success with the triage meetings for Bug 27339 (http://eiximenis.wikimedia.org/Bug27339, summary coming tomorrow) I thought I'd try to do the same thing with wikitech-l and the non-enhancement bugs marked “highest” priority.
Every week, I'll publish a list of these bugs here with a summary of their status. Since I don't always have a good grasp of what is of the most interest to the larger community, I need some feedback on these bugs. If you think there is something that should be on this list that isn't, let me know. Likewise, if you think something on this list should not be here, let me know.
For now, though, I'll just post the one-line summary of the bug and its number. Look these over. If you see one that you think you could take responsibility for, then assign it to yourself. I do ask, though, that a developer has only one highest priority bug. Don't get over-ambitious — I will be nagging you, after all.
So now, the bugs:
28052 Deploy Gender Namespaces on all relevant wikis 27089 Request to move Wikimedia.in to Wikimedia servers 23126 Locked and hidden accounts can unify new local accounts 27537 When SVG file is broken, warn about that, instead of mime failure. 22428 Line breaks in pasted text not picked up in Safari 4, Chrome 4 16976 Wikis ready for creation (tracking) 1319 doBlockLevels inserts pre-tags in a text created by an extension
Hope to hear from you all,
Mark.
On 15/03/11 15:27, Mark A. Hershberger wrote:
1319 doBlockLevels inserts pre-tags in a text created by an extension
How is this high priority? It's easy to work around and affects no actual users. It's just a nuisance for developers who write tag hook extensions, requiring a few extra lines of code.
-- Tim Starling
Tim Starling tstarling@wikimedia.org writes:
On 15/03/11 15:27, Mark A. Hershberger wrote:
1319 doBlockLevels inserts pre-tags in a text created by an extension
How is this high priority?
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 15/03/11 05:27, Mark A. Hershberger wrote:
[..] on-enhancement bugs marked “highest” priority.
Every week, I'll publish a list of these bugs here with a summary of their status. [..]
Thanks for this initiative! It is always great to have a target when doing hacking week-end. You should also have a look at the most voted enhancements bugs.
On Tue, Mar 15, 2011 at 04:32, Ashar Voultoiz hashar+wmf@free.fr wrote:
You should also have a look at the most voted enhancements bugs.
How do you get such a list from bugzilla?
Helder
2011/3/15 Helder h2geral@gmail.com:
How do you get such a list from bugzilla?
Using the advanced search feature, I guess? BZ's options for creating advanced searches are virtually endless (and confusing as a result).
Roan Kattouw (Catrope)
On Tue, Mar 15, 2011 at 3:00 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
2011/3/15 Helder h2geral@gmail.com:
How do you get such a list from bugzilla?
Using the advanced search feature, I guess? BZ's options for creating advanced searches are virtually endless (and confusing as a result).
Like so: http://bit.ly/hRKxXz
On Tue, Mar 15, 2011 at 19:10, OQ overlordq@gmail.com wrote:
Like so: http://bit.ly/hRKxXz
Exactly! Thank you!
Helder
On March, 15 2011, at 23:23 Helder wrote:
On Tue, Mar 15, 2011 at 19:10, OQ overlordq@gmail.com wrote:
2011/3/15 Helder h2geral@gmail.com:
How do you get such a list from bugzilla?
Like so: http://bit.ly/hRKxXz
Exactly! Thank you!
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:
-- Krinkle
On Tue, Mar 15, 2011 at 5:32 PM, Ashar Voultoiz hashar+wmf@free.fr wrote:
You should also have a look at the most voted enhancements bugs. Ashar Voultoiz
We don't really promote the use of the vote feature, in fact last i heard most people wanted it scraped across the whole system since it's basically pointless for most of the developers that use BZ.
Voting is disappearing with the BZ4 upgrade anyway.
-Chad On Mar 15, 2011 4:40 PM, "K. Peachey" p858snake@yahoo.com.au wrote:
On Tue, Mar 15, 2011 at 5:32 PM, Ashar Voultoiz hashar+wmf@free.fr
wrote:
You should also have a look at the most voted enhancements bugs. Ashar Voultoiz
We don't really promote the use of the vote feature, in fact last i heard most people wanted it scraped across the whole system since it's basically pointless for most of the developers that use BZ.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 16/03/11 00:39, K. Peachey wrote:
On Tue, Mar 15, 2011 at 5:32 PM, Ashar Voultoizhashar+wmf@free.fr wrote:
You should also have a look at the most voted enhancements bugs. Ashar Voultoiz
We don't really promote the use of the vote feature, in fact last i heard most people wanted it scraped across the whole system since it's basically pointless for most of the developers that use BZ.
I am probably the only developer looking at the vote field, and I don't even use it to choose a bug to fix :-\
Was just pointing at it because I feel it *could* be used to get feedback from the community as to what is important to them.
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@free.fr wrote:
On 16/03/11 00:39, K. Peachey wrote:
On Tue, Mar 15, 2011 at 5:32 PM, Ashar Voultoizhashar+wmf@free.fr
wrote:
You should also have a look at the most voted enhancements bugs. Ashar Voultoiz
We don't really promote the use of the vote feature, in fact last i heard most people wanted it scraped across the whole system since it's basically pointless for most of the developers that use BZ.
I am probably the only developer looking at the vote field, and I don't even use it to choose a bug to fix :-\
Was just pointing at it because I feel it *could* be used to get feedback from the community as to what is important to them.
-- Ashar Voultoiz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 17/03/11 18:30, Ashar Voultoiz wrote:
I am probably the only developer looking at the vote field, and I don't even use it to choose a bug to fix :-\
I look at it often enough. I suggested category sorting as a project for Aryeh based on its high vote count. I've been beating the drum for bug 189 for the same reason, but I haven't managed to get resources for it yet.
-- Tim Starling
Ashar Voultoiz hashar+wmf@free.fr writes:
I am probably the only developer looking at the vote field, and I don't even use it to choose a bug to fix :-\
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.
Voting has been moved to an extension for BZ4, so if people still want it we'll just need to install that.
-Chad On Mar 18, 2011 8:22 PM, "Mark A. Hershberger" mhershberger@wikimedia.org wrote:
Ashar Voultoiz hashar+wmf@free.fr writes:
I am probably the only developer looking at the vote field, and I don't even use it to choose a bug to fix :-\
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.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ashar Voultoiz hashar+wmf@free.fr writes:
Thanks for this initiative! It is always great to have a target when doing hacking week-end.
Thanks. Of course, I hope we can still get a 1.17 tarball together in a timely manner. Decisions, decisions.
You should also have a look at the most voted enhancements bugs.
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.
#674 is almost ready. It is waiting for someone (most probably me) do the clean up of the patch for about three years.
I have also looked into #83, but stopped because I was unable to determine how should I store those interproject links.
--vvv
On 03/16/2011 02:05 AM, Mark A. Hershberger wrote:
33 Implement the Interlanguage extension in Wikipedia http://bugzilla.wikimedia.org/15607
Some of these are being worked on (#4547, #15607), some have patches
I'd say it's done.
2011/3/16 Mark A. Hershberger mhershberger@wikimedia.org:
116 Support collation by a certain locale (sorting order of characters) http://bugzilla.wikimedia.org/164
This support is now in MW with the category collation code Aryeh wrote, and developers can now proceed to write language-specific collations if they want to. Currently we only support the 'uppercase and 'uca-default' collations. 'uppercase' just runs everything through $wgLang->uc() , 'uca-default' uses UCA (Unicode-based algorithm). I think we want to be using UCA on Wikimedia, but we currently use uppercase because UCA requires packages that aren't currently installed on the Apaches. I hear ops is working on upgrading all Apaches to lucid, though, which will make installing those packages much much easier.
Roan Kattouw (Catrope)
2011/3/15 Mark A. Hershberger mhershberger@wikimedia.org:
28052 Deploy Gender Namespaces on all relevant wikis 27089 Request to move Wikimedia.in to Wikimedia servers
These are shell bugs.
16976 Wikis ready for creation (tracking)
Another shell bug.
I'm not saying they're not important because they're shell bugs, but they are things that can't be fixed by just any developer (needs a sysadmin), so in the specific context of nagging developers they're not very relevant IMO. Of course you should still be nagging people about them, just different people (sysadmins) :)
Roan Kattouw (Catrope)
Roan Kattouw roan.kattouw@gmail.com writes:
2011/3/15 Mark A. Hershberger mhershberger@wikimedia.org:
28052 Deploy Gender Namespaces on all relevant wikis 27089 Request to move Wikimedia.in to Wikimedia servers
These are shell bugs.
16976 Wikis ready for creation (tracking)
Another shell bug.
Good points.
Which means that you and Tim have successfully eliminated several bugs that I could nag people on wikitech-l about. I'll be back Friday with more bugs.
Mark.
Mark A. Hershberger wrote:
Roan Kattouw roan.kattouw@gmail.com writes:
2011/3/15 Mark A. Hershberger mhershberger@wikimedia.org:
28052 Deploy Gender Namespaces on all relevant wikis 27089 Request to move Wikimedia.in to Wikimedia servers
These are shell bugs.
16976 Wikis ready for creation (tracking)
Another shell bug.
Good points.
Which means that you and Tim have successfully eliminated several bugs that I could nag people on wikitech-l about. I'll be back Friday with more bugs.
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
2011/3/16 MZMcBride z@mzmcbride.com:
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'll create an RT ticket for that one.
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.
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain. Previously we just had RobH handle all wiki creations, but he's been working almost exclusively on setting up the Virginia datacenter for a while now AFAIK. I previously suggested on IRC that we could have regular shell users like Ashar do the wiki creations at a scheduled time and assign a root to do the DNS stuff for them.
Roan Kattouw (Catrope)
On Wed, Mar 16, 2011 at 11:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain. Previously we just had RobH handle all wiki creations, but he's been working almost exclusively on setting up the Virginia datacenter for a while now AFAIK. I previously suggested on IRC that we could have regular shell users like Ashar do the wiki creations at a scheduled time and assign a root to do the DNS stuff for them.
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
On 16/03/11 11:38, Roan Kattouw wrote:
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain. Previously we just had RobH handle all wiki creations, but he's been working almost exclusively on setting up the Virginia datacenter for a while now AFAIK. I previously suggested on IRC that we could have regular shell users like Ashar do the wiki creations at a scheduled time and assign a root to do the DNS stuff for them.
Scheduling is a great idea.
Maybe DNS modification could be made to not require root account but just a specific group of well trained people. I have been a dns admin for an ISP in a previous job, currently an architect for network geolocalisation so I probably could apply :p
Of course, this does not fix the actual creation of the wikis.
Roan Kattouw wrote:
2011/3/16 MZMcBride z@mzmcbride.com:
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.
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain. Previously we just had RobH handle all wiki creations, but he's been working almost exclusively on setting up the Virginia datacenter for a while now AFAIK. I previously suggested on IRC that we could have regular shell users like Ashar do the wiki creations at a scheduled time and assign a root to do the DNS stuff for them.
Roan Kattouw (Catrope)
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.
On Wed, Mar 16, 2011 at 6:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain.
Why doesn't Wikimedia just set up a wildcard domain for *.wikipedia.org? They all go to the same IP address anyway, right? Just have the application (maybe Squid) return a 404 if the project doesn't exist.
Aryeh Gregor wrote:
On Wed, Mar 16, 2011 at 6:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain.
Why doesn't Wikimedia just set up a wildcard domain for *.wikipedia.org? They all go to the same IP address anyway, right? Just have the application (maybe Squid) return a 404 if the project doesn't exist.
It does send an error listing a project index, if you try to use a non-existant project.
On Thu, Mar 17, 2011 at 8:49 PM, Platonides Platonides@gmail.com wrote:
Aryeh Gregor wrote:
On Wed, Mar 16, 2011 at 6:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain.
Why doesn't Wikimedia just set up a wildcard domain for *.wikipedia.org? They all go to the same IP address anyway, right? Just have the application (maybe Squid) return a 404 if the project doesn't exist.
It does send an error listing a project index, if you try to use a non-existant project.
It does? I get a DNS error:
On Fri, Mar 18, 2011 at 11:39 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
It does? I get a DNS error:
I think he means for ones that have the DNS zone but not the wiki created.
On 18/03/11 11:19, Aryeh Gregor wrote:
On Wed, Mar 16, 2011 at 6:38 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Normal shell users can execute all but one of the steps required for wiki creation: root access is needed to create the DNS entry for the new subdomain.
Why doesn't Wikimedia just set up a wildcard domain for *.wikipedia.org? They all go to the same IP address anyway, right? Just have the application (maybe Squid) return a 404 if the project doesn't exist.
We used to have a wildcard domain, but Mark removed it when he took over maintenance of the DNS system many years ago, replacing it with a fixed list of CNAMEs based on the language list. Apparently wildcard domains in CNAMEs are not allowed by the spec or cause problems with some clients or something.
Compared to the other things roots have to do, adding a few entries to langlist and running the update script is trivial, so I think developing tools to open this up to more users would be a misuse of time. The difficult things with wiki creation are:
* Finding the bug reports for wiki creations, or remembering to look at a list at appropriate intervals. * Working out which wiki creation requests are properly approved by whatever process it is that we have at the moment. * Interpreting the vague requests by the incubator users for special configuration of the new wiki.
If there is a non-root user who is prepared to do these things, an IRC private message to a root user should be enough to get the DNS changes done in a matter of seconds.
-- Tim Starling
On Thu, Mar 17, 2011 at 11:40 PM, Tim Starling tstarling@wikimedia.orgwrote:
Compared to the other things roots have to do, adding a few entries to langlist and running the update script is trivial, so I think developing tools to open this up to more users would be a misuse of time. The difficult things with wiki creation are:
- Finding the bug reports for wiki creations, or remembering to look
at a list at appropriate intervals.
- Working out which wiki creation requests are properly approved by
whatever process it is that we have at the moment.
- Interpreting the vague requests by the incubator users for special
configuration of the new wiki.
If there is a non-root user who is prepared to do these things, an IRC private message to a root user should be enough to get the DNS changes done in a matter of seconds.
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
Hoi, At the language committee we have several people with knowledge about DNS. We would also positively love the ability to create new projects. Thanks, GerardM
On 18 March 2011 21:11, Brion Vibber brion@pobox.com wrote:
On Thu, Mar 17, 2011 at 11:40 PM, Tim Starling <tstarling@wikimedia.org
wrote:
Compared to the other things roots have to do, adding a few entries to langlist and running the update script is trivial, so I think developing tools to open this up to more users would be a misuse of time. The difficult things with wiki creation are:
- Finding the bug reports for wiki creations, or remembering to look
at a list at appropriate intervals.
- Working out which wiki creation requests are properly approved by
whatever process it is that we have at the moment.
- Interpreting the vague requests by the incubator users for special
configuration of the new wiki.
If there is a non-root user who is prepared to do these things, an IRC private message to a root user should be enough to get the DNS changes done in a matter of seconds.
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org