Re: [Wikitech-l] Who is responsible for communicating changes in MediaWiki to WMF sites?
Thanks Greg for the overview. 0–4 is fine, but there a couple premises I question, which trigger a couple considerations/conjectures which may be of use. First, let's not call the wmfXX subpages release notes. They just are lists of commits. As you noted, they are also created – by design – too late for them to have any substantial content before the commits are deployed, not to speak of being read. Sometimes we (we = whoever happens) managed to get some more information and Wikimedia-specific warnings on them, just because they are the WMF-only pages and there wasn't any other place: but that's not what they're designed for. Moreover, after this there's still nobody tasked with more targeted and actual communication of their content. It's an error in perspective to think that those pages naturally have or will have the information and role you attribute them. Second, There are a lot of changes and I'm unfamiliar with about 100% of them: this is true for all MediaWiki developers and users and it's why release notes exist in the first place. :) If you rely on a hour of asking and poking, 1) you're likely to miss something (example: the only person who knows the real implications of commit Y is sleeping in another timezone) hence nobody will rely on this system, 2) you don't share this information with third party users. Approaching my conclusion: perhaps you need to focus on ensuring that relevant information is added to the RELEASE-NOTES-* files at the time of commit, or before deployment if the system fails and they were not before. This is a shared effort across the board for all devs, but a dev, and especially a volunteer dev, should not *have to* do more than this. Related discussion: https://www.mediawiki.org/wiki/Thread:Manual_talk:Coding_conventions/Release_notes_and_bug_fixes. If we have reliable release notes, it's easier for the release manager to distil important communication from them; if they're also timely, more eyeballs will be on them to fill the occasional gap in understanding. Where and how the WMF wants to put this distillation, is another matter; it also depends on how WMF wants to handle WMF-specific deploy-sensitive stuff (the scaptrap without CR tags problem mentioned earlier): so, yes, IMHO there must be one person responsible of this at WMF. Finally: once problems in steps 0–4 are fixed, the 5th can really have the premise There is now a reasonably good list of important changes and in the process you've also learnt who is affected and what needs doing (flip switch A, notify set of wikis X about B, write blog post Y two weeks before C, set up central notice or magic WMF-users mind-reading tool Z a month before D). Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JobQueue
On Mar 23, 2013 12:10 AM, John phoenixoverr...@gmail.com wrote: I know Aaron has spent a lot of time on the job queue. But I have several observations and would like some feedback. The current workers apparently select jobs from the queue at random. A FIFO method would make far more sense. We have some jobs that can sit there in the queue for extended periods of time, while others added after that point may get completed in mere few minutes. Well random is not the only method. There is also timestamp based and FIFO. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RFC How/whether MediaWiki could use ZendOptimizuerPlus -- ZendOptimizerPlus, opcode cache, PHP 5.4, APC, memcache ???
On 22.03.2013 18:10, Thomas Gries wrote: just one message, just arrived: http://php.net/archive/2013.php#id2013-03-21-1 PHP 5.5.0 beta1 available 21-Mar-2013 The PHP development team announces the release of the first beta of PHP 5.5.0. This release is the first to include the Zend OPCache. Please help our efforts to provide a stable PHP version and test this version carefully against several different applications, with Zend OPCache enabled and report any bug in the bug tracking system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION! Ubuntu 12.04 LTS still has 5.3 which is officially outdated by php.net and does not have traits and also no Closure::bindTo() which makes closures useless as mixin properties via __invoke(). Already had an ugly issue when local php 5.4 closure had access to instance $this while at server running 5.3 it produced an error. Quite strange that closures did not receive instance context in 5.3. And 5.2-style __get() based mixins are slower. And because 12.04 LTS is so much conservative I still cannot rely on 5.4 features in my projects (surely I can add ppa but it's not always a desirable thing). Also 5.4 had some Zend performance optimizations. But it seems they want to move to 5.5 even faster than 5.3 to 5.4 transition. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Missing project ideas AND MENTORS for GSOC
After going in details through all the proposals it turns out we only have 3 project ideas listed at https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas The rest miss a mentor, a more solid justification of relevance and/or a demonstration of interest from the communities they want to help. I have pinged the people that proposed 3 ideas, hoping that we will be able to improve them and list them at the GSOC page: Lua templates http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#.5Bgeneric.5D_Write_useful_Lua_modules We need at least one mentor confirmed, and at lest one proposal identified that would be welcome by the community and would keep a student busy during 12 weeks. I'd really really like to see this one happening. Interwiki notifications framework for InstantCommons http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Build_an_interwiki_notifications_framework_and_implement_it_for_InstantCommons Nice idea and Dereckson is volunteering as mentor but... do we have any idea about how this framework should be developed? Has this proposal been done before? If so, where it is and what the Commons community thinks about it? Improve Extension:CSS http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_Extension:CSS I like this one because it is proposed by a developer of this extension willing to mentor. More reasoning about the need and the implementation proposed would be welcome, and also impressions from other developers / maintainers. Your feedback is welcome at http://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_projects#Improve_.5B.5BExtension:CSS.5D.5D_25458 Then we have another one that looks promising: Bug 46440 - co-ment-like tool for inline comments https://bugzilla.wikimedia.org/show_bug.cgi?id=46440 On 03/22/2013 05:30 AM, Željko Filipin wrote: Browser test automation[1]? http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Browser_Test_Automation 12 weeks of a student to get good coverage of MobileFrontend automated testing? Maybe, but... One thing is the amount of work. Another thing is that it feels like quite volatile / WIP work. I'm open to be convinced, though. On 03/22/2013 05:36 AM, Guillaume Paumier wrote: Hi, This may sound naive, but why are improvements of existing features discarded? Mmm ok, we can try. As you can see Improving Extension:CSS is now a candidate. Still we need to have the rest of pieces in place: mentor, justification, etc. fwiw I pinged the former developers of the Extension:Bugzilla you are proposing at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_the_mediawiki-bugzilla_extension_to_a_deployable_level - see https://twitter.com/quimgil/status/315526551762505728 On 03/22/2013 05:46 AM, Yuvi Panda wrote: I've a good number of Mobile app ideas to contribute, but do not think I'll be able to mentor. Should I still put those in? On 03/22/2013 04:40 PM, phoebe ayers wrote: I have some ideas for existing features and extensions that could use a good summer's work, and I just added one of them to the page, despite not having any ability to personally mentor -- I assumed if there was interest it could get picked up by someone. I hope this is ok! Yes please, at the Possible Projects page. It's good to leave your name as proposer and it's good to tell explicitly that you are not available for mentoring. We will decide whether to list them as GSOC 2013 project ideas or not. But go for the most relevant one explaining it in more detail. You can mention briefly the rest. One good idea without a mentor today still stands a chance. Dumping many ideas with no mentor leave little chances to each. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] JobQueue
Don't forget about the potentials of a priority based queue! (That being said I actually have no idea what goes into our job queues; so can't say if there's good candidates for priority based queuing.) ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Sat, Mar 23, 2013 at 6:30 AM, Tyler Romeo tylerro...@gmail.com wrote: On Mar 23, 2013 12:10 AM, John phoenixoverr...@gmail.com wrote: I know Aaron has spent a lot of time on the job queue. But I have several observations and would like some feedback. The current workers apparently select jobs from the queue at random. A FIFO method would make far more sense. We have some jobs that can sit there in the queue for extended periods of time, while others added after that point may get completed in mere few minutes. Well random is not the only method. There is also timestamp based and FIFO. ___ 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
Re: [Wikitech-l] JobQueue
AFAIK we already do that for some entries, Reedy will know more, I will let you investigate his mind for more knowledge on that. On Sun, Mar 24, 2013 at 7:27 AM, Matthew Walker mwal...@wikimedia.org wrote: Don't forget about the potentials of a priority based queue! (That being said I actually have no idea what goes into our job queues; so can't say if there's good candidates for priority based queuing.) ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Sat, Mar 23, 2013 at 6:30 AM, Tyler Romeo tylerro...@gmail.com wrote: On Mar 23, 2013 12:10 AM, John phoenixoverr...@gmail.com wrote: I know Aaron has spent a lot of time on the job queue. But I have several observations and would like some feedback. The current workers apparently select jobs from the queue at random. A FIFO method would make far more sense. We have some jobs that can sit there in the queue for extended periods of time, while others added after that point may get completed in mere few minutes. Well random is not the only method. There is also timestamp based and FIFO. ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
