>From my position of next to the mozzie bite on the backside of a common breed >of antelope in a backwater of a forest obscured in the middle of the night, ie. a total nonentity in the scheme of things.
AMEN! MZMcBride. Best birthday wishes for bug 7952, enjoy kindergarten. Sometimes the focus on grafting new trunks, and the experimental breeding of new varieties of trunks has allowed people to forget to water the trees that exist, especially as that is where the current fruit is located. (horrid analogy, but heck wax rhetorical) At this point of time my expectations of fixes are close to zero, and for improvements even less. Even where a developer has a fix ready to go, and the bug is causing issues with work it seems that short of being impolite or hammering down someone's door or being a massive whiney butt that nothing progresses. Example? https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 Anyway, I will crawl back to <s>Wikisource</s> my backwater and feed the mosquitoes. Regards, Andrew On 2 Nov 2010 at 19:39, MZMcBride wrote: > Rob Lanphier wrote: > > After review, some (but not all) of the features in the review queue > > then need to be reviewed for checking into the deployment branch. Our > > short term answer to that was the deployment queue: > > http://www.mediawiki.org/wiki/Deployment_queue > > I have a few comments. > > You're chomping at the edges again, but not focusing on the larger issue. > It's still about _WHO_ is going to be deploying these extensions (or doing > general code updates). That question is still unresolved and it's at the > heart of the problem. By focusing on the periphery, you're simply needlessly > adding paperwork (like the new "Deployment queue") without actually > accomplishing anything. Read on for a specific example of why deployment is > sometimes the sole issue, not review. > > The issue with focusing on a "Review queue" is that it puts the focus and > emphasis in the wrong place. Nobody cares about getting their code reviewed > (per se). They want their code live on the site. Most developers don't care > if their code is efficient or not (Domas can speak more to this), they just > want to see their hard work in production. That's why they contribute code > (or contributed, as the case seems to be nowadays). So the emphasis should > be on deployment, a key step of which is code review, to be sure. But > putting the focus on review (as though once review is finished, something > will magically change) is silly and a poor idea. > > Regarding extension deployment in general, one of the issues that seems to > be overlooked is why it's necessary to require individual sites to request > that a feature be enabled. As long as there aren't performance concerns, an > extension should be enabled by default. Let's look at a specific example. > Here's the current configuration for DynamicPageList: > > 'wmgUseDPL' => array( > // controls loading of DynamicPageList extension > 'default' => false, > 'dewiktionary' => true, > 'enwiktionary' => true, > 'incubatorwiki' => true, > 'metawiki' => true, > 'otrs_wikiwiki' => true, > 'srwiki' => true, > 'strategywiki' => true, > 'wikibooks' => true, > 'wikimania2009wiki' => true, > 'wikimania2010wiki' => true, > 'wikimania2011wiki' => true, > 'wikinews' => true, > 'wikiquote' => true, > 'wikiversity' => true, > ), > > Inexplicably, "'wikisource' => true" and "'wikitionary' => true" are > missing. It also sets the default to false, even though the vast majority of > sites could have this extension without any issue. The consequence of this > is that the following bugs are currently open asking for this extension to > be enabled on a Wikimedia wiki: > > nlwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=6163 > iswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 > eswiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 > bswiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=8240 > dewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 > enwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 > hewikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=8563 > viwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=8886 > plwiktionary | https://bugzilla.wikimedia.org/show_bug.cgi?id=11788 > nlwikibooks | https://bugzilla.wikimedia.org/show_bug.cgi?id=15477 > frwiki | https://bugzilla.wikimedia.org/show_bug.cgi?id=19810 > frwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=22250 > itwikisource | https://bugzilla.wikimedia.org/show_bug.cgi?id=25172 > > This is (literally) a two-line change that would resolve a large amount of > old bugs. Of course this doesn't consider that plenty of sites are simply > suffering in silence, having not yet understood how to file a shell bug or, > more likely, having watched the progress of the other bugs, I would imagine > a good number of communities have simply decided to not waste the time > filing a bug that's simply going to be ignored. > > I don't see how this acceptable or desirable, especially given that this is > an example of an extension that has been reviewed, but is purely in the > "deployment" arena now. > > Before someone starts shouting about not considering the performance of > large sites, I'll note that according to my numbers, the largest Wiktionary > by number of pages (enwiktionary) has this extension enabled.[1] Perhaps > there are more complex reasons that this extension can't be enabled > elsewhere; I'd certainly be interested in hearing them. I imagine the people > waiting years for this extension to be enabled would be interested as well. > > Call me pessimistic, call me cynical, call me whatever, but take a look at > https://bugzilla.wikimedia.org/show_bug.cgi?id=7952 and tell how this is > acceptable. This bug will celebrate its fourth birthday this month on > November 16. Somehow I don't think the Icelandic Wiktionary with its 19,000 > pages is going to crash the servers. > > Perhaps the addition of a Bugmeister will allow this type of problem to get > more attention, though I think it's kind of ridiculous that it's going to > require an additional full-time staff member to point out what anyone taking > a minute to research can point out right now. > > MZMcBride > > [1] https://wiki.toolserver.org/view/Wiki_server_assignments > > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
