Re: [Wikitech-l] Fwd: MediaWiki Language Extension Bundle launches
On 28 November 2012 23:54, Platonides wrote: > On 28/11/12 12:28, Niklas Laxström wrote: >> * Running of PHPUnit tests is currently broken > Why? Because of https://bugzilla.wikimedia.org/42529 There is also one test failure I don't know to fix. The test is marked as databaseless but it runs a hook in Translate that accesses a database table. 1) ExtraParserTest::testBug8689 DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT tmi_value FROM translate_messageindex WHERE tmi_key = '0:unit_test' LIMIT 1 Function: DatabaseMessageIndex::get Error: 1 no such table: translate_messageindex -Niklas Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] the skin change in 1.21wmf5, display breakage, & fix retrospective
I still experience the problem on Wikidata main page in Monobook skin. -- Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: IRC office hours about account creation and login redesign
On Nov 28, 2012 9:07 PM, "Isarra Yos" wrote: > > I know the office hours are probably exactly for this kind of question, but I have to ask just for the sake of general interest - are these changes going to be pushed to core, or will they remain in extensions, for instance simply as a permanent feature of enwp only? > During testing they've been mostly in Extension:E3Experiments. For productization (stupid word, I know), we will be making core changes. I need to update the mediawiki dot org docs to reflect the details, but obviously some things will change dramatically from the test version, in order to be fit for deployment in core. > On 28/11/2012 21:51, Steven Walling wrote: >> >> FYI, for developers who might be interested. >> >> -- Forwarded message -- >> From: Steven Walling >> Date: Wed, Nov 28, 2012 at 8:50 PM >> Subject: IRC office hours about account creation and login redesign >> To: Wikimedia Mailing List >> >> >> Hi all, >> >> As you might have noticed, especially if you're an English Wikipedian, the >> Editor Engagement Experiments team has been working on redesigning the >> user experience of account creation, A/B testing new designs and >> functionality for the past couple months. >> >> We finished our final A/B test last week,[1] and we're now moving on to >> make the features which tested well permanent.[2] In order to make sure >> that the experience of signup and login are consistent, we also plan to >> make some changes to the design of login.[3] >> >> In order to answer any questions people might have and gather feedback, >> we're holding the first office hours about our redesign work. We also plan >> to enable the test version of the new account creation experience at 100% >> (rather than 50/50, as previously) so that people can give it a try. >> >> When: Saturday December 1, 2012. 19:00-20:00 UTC. Time conversion links >> etc. are on Meta.[4] >> Where: #wikimedia-office >> > > -- > -— Isarra > > > > ___ > 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] Fwd: IRC office hours about account creation and login redesign
I know the office hours are probably exactly for this kind of question, but I have to ask just for the sake of general interest - are these changes going to be pushed to core, or will they remain in extensions, for instance simply as a permanent feature of enwp only? On 28/11/2012 21:51, Steven Walling wrote: FYI, for developers who might be interested. -- Forwarded message -- From: Steven Walling Date: Wed, Nov 28, 2012 at 8:50 PM Subject: IRC office hours about account creation and login redesign To: Wikimedia Mailing List Hi all, As you might have noticed, especially if you're an English Wikipedian, the Editor Engagement Experiments team has been working on redesigning the user experience of account creation, A/B testing new designs and functionality for the past couple months. We finished our final A/B test last week,[1] and we're now moving on to make the features which tested well permanent.[2] In order to make sure that the experience of signup and login are consistent, we also plan to make some changes to the design of login.[3] In order to answer any questions people might have and gather feedback, we're holding the first office hours about our redesign work. We also plan to enable the test version of the new account creation experience at 100% (rather than 50/50, as previously) so that people can give it a try. When: Saturday December 1, 2012. 19:00-20:00 UTC. Time conversion links etc. are on Meta.[4] Where: #wikimedia-office -- -— Isarra ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: IRC office hours about account creation and login redesign
FYI, for developers who might be interested. -- Forwarded message -- From: Steven Walling Date: Wed, Nov 28, 2012 at 8:50 PM Subject: IRC office hours about account creation and login redesign To: Wikimedia Mailing List Hi all, As you might have noticed, especially if you're an English Wikipedian, the Editor Engagement Experiments team has been working on redesigning the user experience of account creation, A/B testing new designs and functionality for the past couple months. We finished our final A/B test last week,[1] and we're now moving on to make the features which tested well permanent.[2] In order to make sure that the experience of signup and login are consistent, we also plan to make some changes to the design of login.[3] In order to answer any questions people might have and gather feedback, we're holding the first office hours about our redesign work. We also plan to enable the test version of the new account creation experience at 100% (rather than 50/50, as previously) so that people can give it a try. When: Saturday December 1, 2012. 19:00-20:00 UTC. Time conversion links etc. are on Meta.[4] Where: #wikimedia-office -- Steven Walling https://wikimediafoundation.org/ 1. https://meta.wikimedia.org/wiki/Research:Account_creation_UX 2. https://www.mediawiki.org/wiki/Account_creation_user_experience 3. https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Login 4. https://meta.wikimedia.org/wiki/IRC_office_hours -- Steven Walling https://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
On Wed, Nov 28, 2012 at 4:21 PM, Chad wrote: > On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling > wrote: > > Is there a reason not to use the Yahoo championed approach of embedding a > > version number in all static file names so you can set a very long cache > > expires time and just add new versions to the CDN when a change is made? > > > > That's what we used to do for CSS/JS--but we don't serve individual files > like that anymore--they're all served together via the resource loader. > > ResourceLoader actually uses a somewhat more advanced version of the version-number-in-filename approach: it dynamically computes the last modified timestamp of the collection of resources it's requesting, and puts that timestamp in the query string. If the timestamp is not available dynamically, we omit the timestamp, and RL automatically serves the resource with a short cache timeout (5 min) in that case. > Also, it wouldn't have helped much in this case--the problem was that the > HTML/CSS output changed in an incompatible way and we had old (or > new, during the rollback) versions of the HTML still being served via > Squid (they're cached for 30 days, unless something purges them like an > edit). > > "Don't change the HTML in incompatible ways" is probably a good general > rule to live by--but having an easy way to say "start purging all pages on > $theseWikis from Squid/Varnish" would also be nice. > > Yes, the HTML and CSS changed in incompatible ways. The CSS cache invalidated quickly (5-10 mins probably), but the HTML cache didn't. Platonides probably misspoke when he said "cached (skin) CSS had "; I'd imagine it was the Squid-cached HTML instead. Either way, the CSS should be backwards-compatible with the old HTML, and in this case it wasn't. That's the core of the problem. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] the skin change in 1.21wmf5, display breakage, & fix retrospective
Basics: We rolled out 1.21wmf5 to the non-Wikipedia sites today, after a brief reversion and re-deployment to fix breakage in how we were displaying some styling. We are on track to deploy 1.21wmf5 to English Wikipedia on Monday, December 3 per https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap . Below: why this happened and how it got fixed, and what we should change to prevent problems like this in the future. What happened: https://gerrit.wikimedia.org/r/#/c/30361/ changed the headings in the Vector skin. The new code didn't take the WMF config into account, as the author wasn't expecting styles and HTML to be cached in such different ways. The headings were changed from "h4"/"h5", but the CSS used those tags to identify them (instead of using CSS classes). Which means, as expected, that the page layout breaks for up to 30 days. Page cache is controlled by the wiki page content. Unless the page is modified, the cache is kept for up to 30 days for anonymous users. Resource modules, however, are served by ResourceLoader which has its own much more efficient and deployable cache mechanism. But this means that the resources for the skin are deployed globally and site-wide within 5 minutes whereas the HTML isn't for another 2 weeks. The issues that caused were visible in beta labs for the last three days, but none of us realized they were significant, we thought they were caused by a misconfigured memcache; see https://bugzilla.wikimedia.org/show_bug.cgi?id=42452 . We knew that this particular change and the related change https://gerrit.wikimedia.org/r/#/c/34702/ might be problematic and sent out a note about it on Monday -- http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/93.html -- but it looks like we didn't test thoroughly enough on Monday and Tuesday to catch it before the Wednesday deploy. Only anonymous users would have been affected. We don't cache logged-in users in Squid. So logged-in users didn't notice problems on mediawiki.org and test2.wikipedia.org after the first deploy. Problems popped up after the Phase 2 deployment to non-Wikipedia sites, so we reverted the 1.21wmf5 deployment and then redeployed while fixing, purging, etc. Bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=42452 Gerrit changes: https://gerrit.wikimedia.org/r/#/c/35819 , https://gerrit.wikimedia.org/r/#/c/35815/ , https://gerrit.wikimedia.org/r/#/c/35817/ What we should fix for the future: This is why client resources must always be backwards compatible. "Don't change the HTML in incompatible ways" is probably a good general rule to live by--but having an easy way to say "start purging all pages on $theseWikis from Squid/Varnish" would also be nice. get more manual testing on test2.wikipedia.org and mediawiki.org immediately after Phase I deployment, including as anonymous reader and editor to ensure we catch Squid caching issues train more people to review code well, to reduce backlog and catch these kinds of problems? get more people to +2 in core and in important extensions beta labs needs to be trustworthy enough to make this sort of thing a blocker immediately Chris McMahon's take: (for what it's worth, this seems to me to be a sign that beta labs is becoming more and more trustworthy all the time. The more we actually use it, the more we'll understand what does and does not work there. We fixed the memcache problem, which fixed the ability to login, but didn't investigate the display problems because we're used to beta not being very reliable. In this case, beta was reliable, and we didn't understand that. Even with a bug report in bugzilla with 9 subscribers, no one recognized a real issue.) Chris McMahon said: I think this could be framed as an issue of signal, noise, and bandwidth. Beta labs being broken a lot, review backlog in gerrit, false failures in tests are all noise. Given the constraints of ongoing projects, it is difficult to pick out the signal from the noise. We can take steps to reduce the noise so that the signal stands out more by reducing technical debt: make the tests green, make the test environment robust, keep up with code review. (I assembled this just now from IRC & mailing list chatter from several people, and errors are mine -- sorry for missing attributions here. Drafting was on http://etherpad.wmflabs.org/pad/p/nov-28-2012-deploysnafu ) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Wed, Nov 28, 2012 at 12:56 PM, bawolff wrote: > What I would really like to see is banning users from touching the > priority field. The field is made rather useless by bug reporters who > feel their pet issue is the most important thing to ever happen - and > suddenly there's a whole lot of issues at highest. Of course I would > still like to see triaging people setting the field - just not the > randoms who think by marking their bug highest priority it will > actually be treated like highest priority. > > Although Bugzilla isn't a wiki, it might still be helpful to follow the wiki principle of letting it remain easy to fix people's bad changes (e.g. setting the wrong priority) rather than tying their hands from making those changes. Could we instead draw users' attention to the page listing what all the different priorities mean, e.g. by having Bugzilla ask "Are you sure this meets the criteria for a highest priority bug?" and then linking to http://www.mediawiki.org/wiki/Bugzilla/Fields#Priority ? -- Nathan Larson 703-399-9376 http://mediawiki.org/wiki/User:Leucosticte ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Manual testing strategy - DRAFT
Hi, thank you for all your feedback. I have moved the draft to https://www.mediawiki.org/wiki/QA/Strategy And I have integrated the main point of the discussion here: manual testing activities work better in some conditions than others, and bug triaging is needed after them. I have also integrated the sauce of the pre-existing notes in that page, which drove me to create a couple of sections: https://www.mediawiki.org/wiki/QA/Strategy#Follow-up_activities https://www.mediawiki.org/wiki/QA/Strategy#Community_incentives Feel free to keep commenting and polishing. I will still be integrating new feedback, but since Chris is happy about the plan I have moved it to the DONE section of my task list. https://www.mediawiki.org/wiki/User:Qgil#Done PS: feedback and help are always welcome on my current and waiting tasks. In fact this manual testing plan has made my waiting list grow noticeably.. :) -- Quim Gil Technical Contributor Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling wrote: > Is there a reason not to use the Yahoo championed approach of embedding a > version number in all static file names so you can set a very long cache > expires time and just add new versions to the CDN when a change is made? > That's what we used to do for CSS/JS--but we don't serve individual files like that anymore--they're all served together via the resource loader. Also, it wouldn't have helped much in this case--the problem was that the HTML/CSS output changed in an incompatible way and we had old (or new, during the rollback) versions of the HTML still being served via Squid (they're cached for 30 days, unless something purges them like an edit). "Don't change the HTML in incompatible ways" is probably a good general rule to live by--but having an easy way to say "start purging all pages on $theseWikis from Squid/Varnish" would also be nice. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
Is there a reason not to use the Yahoo championed approach of embedding a version number in all static file names so you can set a very long cache expires time and just add new versions to the CDN when a change is made? I don't know how often our CSS, branding images, scripts, and other static content change, but there would not be much effort in adding that to a deploy process and there must be developer overhead being incurred in trying to keep new code backwards compatible. Luke Welling On Wed, Nov 28, 2012 at 5:52 PM, Platonides wrote: > Code was updated to use while the (cached) skin CSS still had > > See > > http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/93.html > > Note: code was reverted to wmf4, so the problem will appear now in the > reverse. > > We should use an intermediate CSS with rules appliying to portlets no > matter if they are h3 or h5. Then migrate again in a few days. > > > > ___ > 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] WMF's webpage
Code was updated to use while the (cached) skin CSS still had See http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2012-November/93.html Note: code was reverted to wmf4, so the problem will appear now in the reverse. We should use an intermediate CSS with rules appliying to portlets no matter if they are h3 or h5. Then migrate again in a few days. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
On Nov 28, 2012, at 11:29 PM, Samat wrote: > Hi, > > I am the only one, who see this (in attachment) on the top of WMF's Main > Page (https://wikimediafoundation.org/wiki/Home)? > Looks like that one got purged in the mean time. I currently see it on: https://wikimediafoundation.org/wiki/FAQ/en This is caused by the recent change to the headings in the Vector skin. They were changed from h4/h5, however the CSS used those tags to identify them (instead of using css classes). Which means, as expected, that the page layout breaks for up to 30 days. Page cache is controlled by the wiki page content. Unless the page is modified, the cache is kept for up to 30 days for anonymous users. Resource modules, however, are served by ResourceLoader which has its own much more efficient and deployable cache mechanism. However this means that the resources for the skin are deployed globally and site-wide within 5 minutes. Whereas the html isn't for another 2 weeks. This is why client resources must always be backwards compatible. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
On Wed, Nov 28, 2012 at 11:40 PM, Samat wrote: > On Wed, Nov 28, 2012 at 11:31 PM, Bináris wrote: > >> 2012/11/28 Samat >> >> > Hi, >> > >> > I am the only one, who see this (in attachment) on the top of WMF's Main >> > Page (https://wikimediafoundation.org/wiki/Home)? >> > >> >> The same thing is happening in Wikidata, see >> https://www.wikidata.org/wiki/Wikidata:Project_chat#Dafuq.3F and the main >> page. >> >> -- >> Bináris > > > Thanks! > > Something happened, because it works well for me now. > > Samat > But Meta-Wiki doesn't... https://meta.wikimedia.org/wiki/Main_Page Samat ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
On Wed, Nov 28, 2012 at 11:31 PM, Bináris wrote: > 2012/11/28 Samat > > > Hi, > > > > I am the only one, who see this (in attachment) on the top of WMF's Main > > Page (https://wikimediafoundation.org/wiki/Home)? > > > > The same thing is happening in Wikidata, see > https://www.wikidata.org/wiki/Wikidata:Project_chat#Dafuq.3F and the main > page. > > -- > Bináris Thanks! Something happened, because it works well for me now. Samat ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF's webpage
2012/11/28 Samat > Hi, > > I am the only one, who see this (in attachment) on the top of WMF's Main > Page (https://wikimediafoundation.org/wiki/Home)? > The same thing is happening in Wikidata, see https://www.wikidata.org/wiki/Wikidata:Project_chat#Dafuq.3F and the main page. -- Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WMF's webpage
Hi, I am the only one, who see this (in attachment) on the top of WMF's Main Page (https://wikimediafoundation.org/wiki/Home)? Best regards, Samat <>___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: MediaWiki Language Extension Bundle launches
On 28/11/12 12:28, Niklas Laxström wrote: > * Running of PHPUnit tests is currently broken Why? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jenkins now lints javascript!
Krinkle This is awesome. In honour of this awesome development I made integrating this with MobileFrontend my first task [1] on return from vacation: MobileFrontend now has much cleaner code [2]. Great work! :) [1] https://gerrit.wikimedia.org/r/#/c/35788/ [2] https://gerrit.wikimedia.org/r/#/c/35789/ On Thu, Nov 22, 2012 at 12:02 PM, Krinkle wrote: > .jshintrc -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Tech Chat: Mobile QA & newbie dev tutorial tumorrow
Tomorrow, we have two topics on the agenda for the weekly tech chat / brown bag: * a mobile QA guest speaker: Pete Hodgson, with Khali Young from ThoughtWorks, will talk about automated testing (and cross-platform development strategies). See Pete's blog at: http://blog.thepete.net/ * Sumana is planning a walkthrough on "how to fix a bug" from start to finish, suitable for newbie developers. As always, will be live-streamed, recorded, transmogrified, etc. Sign up here, come in person or on #wikimedia-dev tomorrow: https://www.mediawiki.org/wiki/Meetings/2012-11-29 Cheers, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper wrote: > Right now I'd like to introduce a clear way to mark issues that should > be handled immediately. This. Also On Wed, Nov 28, 2012 at 9:56 AM, bawolff wrote: > An alternative way of looking at priority, is instead of how long it > should take to fix - look instead at how long it should take before > somebody starts to look into/begin fixing the issue. I'm comfortable with this as a compromise. Also, it's worth noting that the most productive use of Bugzilla is going to be for things that take less than a month of dedicated, focused developer time. Any task that's bigger should be broken down into smaller tasks. Using the moon landing metaphor, it's not as though the NASA folks basically went to work every day saying "this is the day we're going to land on the moon", trying and failing every day until July 21, 1969. There were a few interim steps in there, and heck, I'll bet you they even wrote them down somewhere. Point being: it's fine for something big to be "highest" priority, so long as it's a tracking bug, and there's a smaller subtask somewhere that is also "highest". I would maintain that the subtask is the *only* thing that should have "highest" priority, because saying that the ultimate goal is the "highest" priority, while maybe strictly accurate, is an empty gesture. It doesn't help us organize our work. It's also not even terribly accurate, since the whole "landing on the moon" thing wasn't the highest priority until Apollo 11 got to the moon, and before that got off the ground, and before that...yadda yadda. Yes, it was always helpful to have the ultimate goal in mind, but I'm going to go out on a limb and say that they didn't use an issue tracker for that. However, I don't care as we take care of this: On Wed, Nov 28, 2012 at 5:32 AM, Andre Klapper wrote: > Right now I'd like to introduce a clear way to mark issues that should > be handled immediately. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
It was here http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/bugzilla-3.4.4/scripts/bugzilla_report.php?view=log My last correspondence was with one of our former engineers Priyanka who was going to integrate it back in 2010. Doesn't look like that ever happened before she left. --tomasz --tomasz On Wed, Nov 28, 2012 at 7:42 AM, Andre Klapper wrote: > On Mon, 2012-11-26 at 03:00 +, reporter wrote: > > MediaWiki Bugzilla Report for November 19, 2012 - November 26, 2012 > > Trying to locate the script creating this weekly email, I found > wikimedia/bugzilla/modifications/bugzilla-3.6.2/scripts/bugzilla_report.php > in Gerrit. > We're running Bugzilla 4.0 currently, and > wikimedia/bugzilla/modifications/bugzilla-4.0/ does not include such a > script. > > Does any historian know if it was just forgotten to drop the file in SVN > (now Gerrit) in the "bugzilla-4.0" folder? Mark, maybe? > > Thanks, > andre > -- > Andre Klapper | Wikimedia Bugwrangler > http://blogs.gnome.org/aklapper/ > > > ___ > 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] Priorities in Bugzilla
On Wed, Nov 28, 2012 at 9:32 AM, Andre Klapper wrote: > On Tue, 2012-11-27 at 22:23 +, Tim Landscheidt wrote: >> If at the moment the priority field neither necessarily >> triggers action nor reflects the actual state of affairs, >> why even bother and not just delete/hide it from view? This >> would free more time to fix bugs. > > I don't see how dropping it all together helps planning or how it "frees > more time". Obviously anybody is free to work on anything but some stuff > simply is more important than other stuff. > I understand that there are many options and ways to express that > importance though, and that "severity", "priority", "target milestones", > "blocker bugs" have some ambiguity to discuss in the long run. > Right now I'd like to introduce a clear way to mark issues that should > be handled immediately. > I think the priority field is important. And I sometimes use it for finding bugs to fix (or you know, did back when I had more free time and went around fixing random bugs). What I would really like to see is banning users from touching the priority field. The field is made rather useless by bug reporters who feel their pet issue is the most important thing to ever happen - and suddenly there's a whole lot of issues at highest. Of course I would still like to see triaging people setting the field - just not the randoms who think by marking their bug highest priority it will actually be treated like highest priority. Some of the suggestions mentioned earlier for priority meanings seem a bit inflated to me. At most times there's not a huge number of high priority issues (Limited person power = not everything can be fixed instantly) - Thus the field should be more distinguishing on the lower end of the spectrum. I personally think that the following would more reflect reality: lowest = nobody cares. If somebody cares they can fix it, and we won't stop them low = Not very important. Maybe one day if I'm very bored. If this issue never got fixed I wouldn't loose too much sleep Normal = Your average bug (Realizing that your average bug isn't very important). This should get fixed at some point. Doesn't have to be at next release - But if I was browsing Wikipedia 5 years from now I hope I don't encounter the issue High = This was kind of bad. Unless there is some very good reason we cannot, this should be fixed by next release. Preferably in the next month if it is not a large amount of work Highest = This is a major issue. Somebody should be working on this right now. If somebody sets this to high they should either be working on the issue, or working to find someone to fix the issue. An alternative way of looking at priority, is instead of how long it should take to fix - look instead at how long it should take before somebody starts to look into/begin fixing the issue. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Newbie licensing questions
On Wed, Nov 28, 2012 at 12:18 PM, Luke Welling wrote: > The questions: > Is my assumption that by default we put everything under GPL2 right? > Are other FS/OSS licences OK to use? Generally, I think the consensus has been "GPLv2 preferred, but any FLOSS license is probably ok." I know there's more than a few extensions that are Apache or MIT licensed. > How paranoid are we? ie do we make a good faith effort at getting it right, > or do we refer questions to internal counsel for a slower but safer answer? > We just assume good faith :) > In this case my inclination is to licence the whole extension (containing > the external library) as Apache2.0 but I'm happy to defer to normal process > if there is one. > If you can't use an Apache library in a GPL extension, then licensing the whole extension as Apache is probably fine. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Newbie licensing questions
These are prompted by Gerrit review comments, but it seems like a hidden place to discuss them. The specific background: A task I am on uses an external library licensed under the Apache2.0 license. Mediawiki core is shipped under a GPL2 license, so I'm guessing that is the default licence fondation work is released under. According to http://en.wikipedia.org/wiki/Apache_License#GPL_compatibilityApache licenses are compatible with GPL3 but not GPL2. The questions: Is my assumption that by default we put everything under GPL2 right? Are other FS/OSS licences OK to use? How paranoid are we? ie do we make a good faith effort at getting it right, or do we refer questions to internal counsel for a slower but safer answer? In this case my inclination is to licence the whole extension (containing the external library) as Apache2.0 but I'm happy to defer to normal process if there is one. Thanks, Luke Welling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, 2012-11-26 at 03:00 +, reporter wrote: > MediaWiki Bugzilla Report for November 19, 2012 - November 26, 2012 Trying to locate the script creating this weekly email, I found wikimedia/bugzilla/modifications/bugzilla-3.6.2/scripts/bugzilla_report.php in Gerrit. We're running Bugzilla 4.0 currently, and wikimedia/bugzilla/modifications/bugzilla-4.0/ does not include such a script. Does any historian know if it was just forgotten to drop the file in SVN (now Gerrit) in the "bugzilla-4.0" folder? Mark, maybe? Thanks, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Standardizing highest priority in Bugzilla
On Wed, 2012-11-28 at 00:36 +0100, Krinkle wrote: > I don't think adding more fields/values is the solution. Perhaps use milestone > for "immediate"? Currently milestones are used in "MediaWiki" for tarballs (that we don't create for MW 1.21), in "VisualEditor" for deployments (VE-2012-12-34), and globally in "MediaWiki Extensions" for branches refering to a MediaWiki version. See my last two lines down there in this email. > So both "Get man on the moon (tracking)" and "[Regression] Bike shed should > not > be on fire" have highest priority. But one is a regression milestoned for the > current release, and the other is on track for N+2 release or maybe "Future > release". For the "MediaWiki" Bugzilla product: The conflict would be "wmf deployments" vs "MW tarballs". We currently use TMs for MW tarballs and we have a "1.20.x", "1.21.0" there. We tag regressions with a "code-update-regression" keyword. For issue that should block wmf deployments the blocker bug 38865 is used (which is not great but I plan to tackle this later, not now). > Besides an "immediate" bug without a milestone doesn't make sense to start > with? > If that is possible, there is a missing milestone I guess. It's possible. Immediate means immediate. ;) If it should block wmf deployment, also mark it as blocking bug 38865. If it should block an MW tarball, set the Target Milestone accordingly. > We should make more use of being able to combine and query different fields to > express clarity instead of adding more options that represent a multiple of > values in other fields which then also need to be set separately I agree in the long run, but it might interfere with teams and their use of Bugzilla again. Global workflows vs. "this works for my team". Right now I'd like to introduce a clear way to mark issues that should be handled immediately. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Tue, 2012-11-27 at 22:23 +, Tim Landscheidt wrote:
> If at the moment the priority field neither necessarily
> triggers action nor reflects the actual state of affairs,
> why even bother and not just delete/hide it from view? This
> would free more time to fix bugs.
I don't see how dropping it all together helps planning or how it "frees
more time". Obviously anybody is free to work on anything but some stuff
simply is more important than other stuff.
I understand that there are many options and ways to express that
importance though, and that "severity", "priority", "target milestones",
"blocker bugs" have some ambiguity to discuss in the long run.
Right now I'd like to introduce a clear way to mark issues that should
be handled immediately.
> Not to quote from another video about GitHub (where "issues"
> have only title and comment), let's not forget Git: No bug-
> tracker at all :-).
I'm happy if using http://dir.gmane.org/gmane.comp.version-control.git
works well for the Git developers and if important issues don't get
lost. There are many ways and tools how to do software development, some
work well for some, others work well for others, and not every tool is
needed by everybody.
GitHub itself has a bugtracker ("Issues" tab) by the way.
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikivoyage.com
2012/11/28 Sébastien Santoro > Hello, > > On Wed, Nov 28, 2012 at 11:00 AM, Bináris wrote: > > Will Wikivoyage be under SUL? If so, when? > > Wikivoyage is already under SUL. > You are right, my fault was to come from .com. It works when using .org directly. Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: MediaWiki Language Extension Bundle launches
FYI. I will not be posting release announcements here, but feedback on the implementation is welcome. Code is at: https://gerrit.wikimedia.org/r/gitweb?p=translatewiki.git;a=tree;f=melange Maybe there is interest in making it more generic and use it to make other extension bundles too. In that case it we could create own repo for it. Some known TODOs on top of my head: * Signing the archive * Running of PHPUnit tests is currently broken * QUnit tests need to be run manually -Niklas -- Forwarded message -- The Wikimedia Language Engineering team is pleased to announce the first release of the MediaWiki Language Extension Bundle. The bundle is a collection of selected MediaWiki extensions needed by any wiki which desires to be multilingual. This first bundle release (2012.11) is compatible with MediaWiki 1.19, 1.20 and 1.21alpha. Get it from https://www.mediawiki.org/wiki/MLEB The Universal Language Selector is a must have, because it provides an essential functionality for any user regardless on the number of languages he/she speaks: language selection, font support for displaying scripts badly supported by operating systems and input methods for typing languages that don't use Latin (a-z) alphabet. Maintaining multilingual content in a wiki is a mess without the Translate extension, which is used by Wikimedia, KDE and translatewiki.net, where hundreds of pieces of documentation and interface translations are updated every day; with Localisation Update your users will always have the latest translations freshly out of the oven. The Clean Changes extension keeps your recent changes page uncluttered from translation activity and other distractions. Don't miss the chance to practice your rusty language skills and use the Babel extension to mark the languages you speak and to find other speakers of the same language in your wiki. And finally the cldr extension is a database of language and country translations. We are aiming to make new release every month, so that you can easily stay on the cutting edge with the constantly improving language support. The bundle comes with clear installation and upgrade installations. The bundle is tested against MediaWiki release versions, so you can avoid most of the temporary breaks that would happen if you were using the latest development versions instead. Because this is our first release, there can be some rough edges. Please provide us a lot of feedback so that we can improve for the next release. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikivoyage.com
Hello, On Wed, Nov 28, 2012 at 11:00 AM, Bináris wrote: > Will Wikivoyage be under SUL? If so, when? Wikivoyage is already under SUL. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] git-review reaches the FreeBSD ports tree
Good morning, I'm glad to announce git-review 1.20 is now available in the FreeBSD port tree. Installation: cd /usr/ports/devel/git-review/ make install Vocabulary: - a port in FreeBSD is a Makefile "cookbook" to download, compile when needed and install an application; - a package is the binary distribution prepared from this port; it is automatically generated from FreeBSD build machines. I will maintain this port. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikivoyage.com
Will Wikivoyage be under SUL? If so, when? -- Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Priorities in Bugzilla
On Tue, Nov 27, 2012 at 11:23 PM, Tim Landscheidt wrote: > [...] > Not to quote from another video about GitHub (where "issues" > have only title and comment), let's not forget Git: No bug- > tracker at all :-). > > Tim According the http://git-scm.com/community page: "Bug reports should be sent to this mailing list." So it seems the Git development mailing list is the bug tracker. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
