http://blog.gmane.org/gmane.comp.mozilla.devel.seamonkey hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12374 Having returned from holiday, I am instigating a period of discussion about what further changes might usefully be made to bugzilla.mozilla.org's product and component hierarchy. I expect this set of changes to be far less extensive than the first set. A wiki page tracks all the currently-suggested ideas: https://wiki.mozilla.org/BMO_Reorg_Phase_2 If your idea isn't on there, please comment in mozilla.dev.planning to start discussion of it. Please let me know of any bugs filed on things to change which have not made it on there either. Concrete proposals are everything - don't expect your idea to make it on to the wiki page unless you make one. Gerv Gervase Markham 2008-08-21T15:23:09 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12363 The next Gecko 1.9.1/Shiretoko meeting will be on Wednesday at 11am PDT. See below for meeting time, location, and agenda. For a general list of planning and status pages for each functional group of the Mozilla platform see: http://wiki.mozilla.org/Platform Meeting Details: * Agenda: http://wiki.mozilla.org/Platform/2008-08-20 * Wednesday, August 20, 11:00 am PDT * 650-903-0800 x91 Conf# 8605 (US/INTL) * 1-800-707-2533 (pin 369) Conf# 8605 (US) * join irc.mozilla.org #shiretoko for back channel - Vlad Vladimir Vukicevic 2008-08-20T16:02:38 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12356 There will be no Mac Gecko status meeting today. Cheers, Josh Aas joshmoz< at >gmail.com 2008-08-20T14:00:41 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12350 one thing that i'd suggest is that you can actually setup your own mini hg repo for testing things. it was of course possible w/ cvs too, but i doubt many people did it. for hg, it's probably worth it to create mini repos and test commands in them, i've included a useless example at the end of this [1]. i use EDITOR=vi hg commit or something, that lets me specify a multiline commit message. on windows, if notepad worked, i'd use it. (long ago, i'd have used pico, but it isn't available everywhere, so i've fallen back to vi on unix) updating things is interesting, one approach is to do the changes requested by the reviewer commit those (preferably referencing bug and comment number, or url to bug-comment). and then when you're ready, you can push the set. people will probably recommend mq as it's sorta the logical way of dealing w/ "not ready" patches, such that they don't harm your repo. there are wiki pages for it. "forget it" ;-). http://robarnold.org/hg-qimport-my-bugzilla-patch/ hg commit -u 'First Last <user< at >host.tld>' the message should include the bug number, summary a line for the reviewer(s) and if you can figure out a useful description beyond that, extra lines/paragraphs for that. if a patch has evolved and includes contributions from multiple people, then i'd really suggest that you (and everyone else) consider using multiple commits, one for each contributor. this is open to discussion (and this thread isn't the right one), in some cases, if a reviewer has spelled out exactly what to change, it might make sense to do a commit as the reviewer for those changes. the commit message would point to the bug/comment and indicate that you're just copying exactly what was written. if you do this. then you should use hg bundle and put it somewhere that the reviewer could look at so that the reviewer could agree that their name was used in an acceptable manner. irc.mozilla.org #hg irc.freenode.net #mercurial you didn't ask about merging, so i'm assuming you have a solution for merging. IME you're not going to be able to retrieve a patch, commit, compile, test, and push w/o finding that someone has already pushed before you. but dealing w/ pulling and merging or rebasing is something which i'm sure is described somewhere else. [1] useless example of using /tmp to test hg to see what it will do. cd /tmp mkdir hg-test-1 cd hg-test-1 hg init echo "hello" > first hg add first hg commit -m "initial" -u "upstream" echo "world" >> first hg commit -m "fixing message" -u "fixer" hg up -r 0 echo "world" > second hg add second hg commit -m "disjoint" -u "other guy" hg up -r 1 # this actually fails, and is your first introduction to mercurial hg up -r 0; hg up -r 1 # that's just stupid of me, but my repo is small enough that i can do it # the correct way is to follow the instructions from the error message... hg merge hg commit -m "merging other guy's stuff" -u "merge guy" hg log hg clone .#1 ../hg-test-2 hg log -R ../hg-test-2 cd ../hg-test-2 hg cp first second hg commit -m "copying first to second" -u "conflict maker" hg pull /tmp/hg-test-1/ hg merge # this should generate a conflict, in my case, conflicts seem to go to std out hg commit -m "i don't care about upstream" -u "conflict maker" hg push /tmp/hg-test-1/ hg clone .#0 ../hg-test-3 cd .. mv hg-test-1 hg-test-0; mv hg-test-3 hg-test-1 cd hg-test-2 hg push feel free to do hg log at times, or enable glog and use hg glog... note that the clone # syntax is really undocumented and unsupported. and by the time you're done pulling a second time, you're going to want to change hgrc so that it has something else. actually, the # syntax has one interesting benefit. it means that if you try to push or pull, nothing will happen, well, unless of course things go missing as happened when we pushed from 2 into 3 named 1. That is actually an example of why you can't ever really delete versions from your repo, try as you might, they're like weeds, they'll keep coming back. timeless 2008-08-20T09:15:54 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12347 i'm actually in favor of this, as it'll help w/ my pet project, however i'm going to need some advice about how it should actually work. currently mxr checks out each root individually, unless there's some magical intervention involved. (mozillasvn v. mozillasvn-all is an example) if there's a single unified repo, then ideally mxr should be able to have a single copy of the .hg/ store, and only pull it once, and just use update in the individual roots. it'd be nice if someone contacted me / reed w/ enough time for us to make sure we have some decent design for this before it happens. I was given a vm to play w/, and I've spent 40gb out of 95gb already. I'm fairly certain that I'd like to save space in that vm and also for the real mxr and mxr-stage if we can, and this plan *should* enable that. i think i'd kinda like for mxr to be able to detect and automatically provide additional roots for hg branches at least of mozilla-central, advice on how such hooks might work will also be appreciated (queue it via email, it shouldn't be urgent). timeless 2008-08-20T08:32:06 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12343 Need some help tracking down this info: * OS_VERSION strings for Mac older than 10.4 (so I can write a regex) * How to detect Linux with GTK older than 2.10 in app.update.url -- is this a part of OS_VERSION? Anybody have examples? This is blocking me on some major update tasks. If you have some answers, please ping me or reply in bug 418129. Backup plan is to parse some logs but if someone has more info it'd be helpful. Thanks, Mike morgamic 2008-08-19T19:23:29 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12342 Hey folks, Usual time, usual place: https://wiki.mozilla.org/Firefox3.1/StatusMeetings/2008-08-19 Meeting Details * Tuesdays - Firefox 3 - 11:00am Pacific, 2:00pm Eastern, 18:00 UTC * Mozilla Building S * 650-903-0800 or 650-215-1282 x91 Conf# 8605 (US/INTL) * 1-800-707-2533 (pin 369) Conf# 8605 (US) * irc.mozilla.org #shiretoko for backchannel Agenda: - Major Update 2.0.0.16 -> 3.0.1 - 2.0.0.17 / 3.0.2 - 3.1 Alpha 2 - Roundtable cheers, mike Mike Beltzner 2008-08-19T17:50:05 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12341 As of 1.9.1a2pre Software Update (now Toolkit -> Application Update in bugzilla) requires an additional section for locale to the localized updater.ini file as follows: [Installation] Locale=en-US where en-US is the locale that is being distributed. See Bug 446527 for more information as to why this change is necessary. It is currently mandatory that this is present in the updater.ini and I am working on making it optional. This will likely be backported to 1.9.x with a fallback to the previous method of using the general.useragent.locale preference for the locale. also cc'd to dev-platform - please reply to dev-planning Cheers, Robert Robert Strong 2008-08-19T17:11:24 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12328 There are nearly 50 bugs (8 are mine). Is there a plan to check them in, preferably before tomorrow' FF 3.1a2 freeze ? Thanks. Serge Gautherie 2008-08-18T09:03:48 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12327 Meeting Details: * 1:00pm Pacific time (20:00 UTC) * Mozilla HQ, 1st floor conference table * +1 650 903 0800 x91 Conf# 8600 (US/International) * +1 416 848 3114 x91 Conf# 8600 (Canada) * +1 800 707 2533 (pin 369) Conf# 8600 (US Toll Free) * join irc.mozilla.org #staffmeeting for backchannel Add your agenda items/status here prior to the meeting: https://wiki.mozilla.org/WeeklyUpdates/2008-08-18 Reed Loden 2008-08-18T04:24:09 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12326 Hi Everyone, Just another friendly reminder to join us Tuesday in #bugday on irc.mozilla.org : *Tuesday, 19. August 2008 :* * Asia session - 14:00-16:00 (Beijing) * Euro session - 14:00-16:00 (Berlin) * Amer. session - 12:00-14:00 (Los Angeles) See also the timetable on http://quality.mozilla.org/events/bug-days#Schedule for your Timezone. On Bugday on Tuesday, August 19, 2008, we will check unconfirmed Firefox Software-Update Bug Reports. Please use this Bug Query http://tinyurl.com/687gtk and check this bug reports if you can confirm them. For more information about Bugdays, please see:http://quality.mozilla.org/events/bug-days Hope to see you in Bugday ! Tomcat Team Mozilla QA Carsten Book 2008-08-16T22:16:08 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12310 [X-Post and F'up 2 set to mozilla.dev.planning] Hi! Right now, every change in a translation of TB2 needs a separate bug report and a specific approval from the relevant l10n coordinator. In the past that was Axel Hecht, now it's me as I have taken over as TB l10n coordinator. The reason for this rule was probably that the same rule existed for Firefox l10n so it was applied to Thunderbird as well. The underlying reason was, as Axel told me, that in the past people did check in broken stuff, which borked their localization. In my opinion, this mostly applies to Firefox, but not to Thunderbird. The reason is that Firefox has always been the first target of localizers. With Firefox people learn how the Mozilla l10n process works, they learn to use cvs (and now hg) and some people make mistakes on their journey to get a working Firefox localization and even afterwards. Once people start translating Thunderbird they've already much experience in our way of doing things and the risk of errors is way lower. Therefore I'm planning to loosen the checkin rules for TB l10n changes on stable branches by removing the need for the specific approval from me and only requiring localizers to open up bugs for their proposed changes and informing me on those (by CC'ing me on that bug). I'd be interested in getting feedback on that proposal. Cya Simon Paquet Simon Paquet 2008-08-15T21:10:56 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12309 During this time we will be landing two things: * Test reporting to graphs.mozilla.org for codesighs and leak tests on mozilla-central ( <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=433710">bug 433710</a>) * Support for pushing try server builds to an hg.m.o repository (details later) (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=448014">bug 448014</a>) No downtime is expected. If there is any reason why we shouldn't go ahead with this please e-mail release< at >mozilla.com Ben Hearsum 2008-08-15T20:53:06 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12303 Hi everyone, The next five days will be busy as we freeze up for the next security and stability milestones on our release branches as well as the upcoming Shiretoko milestone. As always, you can keep up with the latest release schedules at http://wiki.mozilla.org/Releases - Firefox 2.0.0.17 & Firefox 3.0.2 --- Code freeze for these releases is Friday, August 15th at 11:59pm PDT. If you own a bug marked as blocking either of these releases, or a patch with approval which has not yet been checked in, please attempt to do so before the freeze. Both trees are now open for checkins, please observe the tree rules and check with the sheriff: For Firefox 2.0.0.17 bug queries and tree status, see http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8 For Firefox 3.0.2 bug queries and tree status, see http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.0 - Shiretoko (Firefox 3.1) Alpha 2 --- As discussed at this week's product delivery meeting on Tuesday (notes at https://wiki.mozilla.org/Firefox3.1/StatusMeetings/2008-08-12) the next Shiretoko milestone will be Alpha 2, with code freeze set for Tuesday, August 19th at 11:59pm PDT. As an alpha, this milestone will be en-US only, so there is no string freeze date. cheers, mike Mike Beltzner 2008-08-15T04:50:21 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12288 Yesterday I closed the tree for bug 450401, which is a 10% Tp performance regression that appeared on XP, OSX and Linux from Aug. 7th. We appear to have tried backing out every changeset that was in the affected range. We also asked for a clobber of the relevant boxes. There has been no improvement. dolkse as sheriff reopened the tree last night because the regression was unexplained, but I don't think this is the right course of action... we still have an unexplained regression, and piling more checkins on top of it is only going to make things worse. Possible actions include: * testing the nightly builds from before/after the regression appeared on depend builds, to see if the regression is noticed in nightlies * reverting the tree to a known-good state well before the regression appeared Are there other possibilities? Considering that we've backed out every reasonable suspect, I'd like to think this is some kind of fluke with the testing infrastructure, but the fact that it appear on all three platforms makes that seem less likely. --BDS Benjamin Smedberg 2008-08-14T13:46:49 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12281 In order to streamline the buildslave pool, the names of the following unittest 1.9 slaves were changed when we switched networks yesterday. All of these machines now run Buildbot 0.7.7 and the latest Twisted & Python. The Linux machines had their names changed and user changed - they are the same VMs as before: qm-centos5-01 --> fx-linux-1.9-slave07 qm-centos5-02 --> fx-linux-1.9-slave08 qm-centos5-04 --> fx-linux-1.9-slave09 The Mac machines are the same ones as before, only a user change: qm-xserve01 --> bm-xserve? qm-xserve06 --> bm-xserve? The two non-pgo windows machines are now VMs, the pgo box is the same VM that it was before - with a user change and a new 30GB fcal drive added for building on qm-win2k3-01 --> fx-win32-1.9-slave07 qm-win2k3-02 --> fx-win32-1.9-slave08 qm-win2k3-pgo01 --> fx-win32-1.9-slave09 At the moment all three Linux boxes are experiencing errors in Check : gmake[2]: Leaving directory `/builds/slave_new/trunk_centos5_8/mozilla/ objdir/storage/build' gmake[2]: Entering directory `/builds/slave_new/trunk_centos5_8/ mozilla/objdir/storage/test' ../../_tests/xpcshell-simple/test_storage/unit/test_bug-365166.js: FAIL ../../_tests/xpcshell-simple/test_storage/unit/test_bug-365166.js.log: *** Storage Tests: Trying to close! *** Storage Tests: Trying to remove file! *** test pending [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [mozIStorageService.openDatabase]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: ../../_tests/xpcshell-simple/test_storage/unit/ test_bug-365166.js :: test :: line 22" data: no] *** FAIL *** <<<<<<< ../../_tests/xpcshell-simple/test_storage/unit/test_bug-393952.js: PASS ../../_tests/xpcshell-simple/test_storage/unit/test_bug-444233.js: PASS And all three Win32 boxes are having the same 1 test fail in Reftest: REFTEST UNEXPECTED FAIL: file:///E:/slave/trunk_2k3_8/mozilla/layout/reftests/bugs/212563-1.html Please contact me if you have any ideas about what could be causing these. lsblakk 2008-08-13T20:25:18 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12276 All, No mac call today. A status will be updated in place of today's usual meeting here: https://wiki.mozilla.org/Platform/Mac Cheers, Damon Damon Sicore 2008-08-13T16:20:30 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12275 The next Gecko 1.9.1/Shiretoko meeting will be on Wednesday at 11am PDT. See below for meeting time, location, and agenda. For a general list of planning and status pages for each functional group of the Mozilla platform see: http://wiki.mozilla.org/Platform Meeting Details: * Agenda: http://wiki.mozilla.org/Platform/2008-08-13 * Wednesday, August 13, 11:00 am PDT * 650-903-0800 x91 Conf# 8605 (US/INTL) * 1-800-707-2533 (pin 369) Conf# 8605 (US) * join irc.mozilla.org #shiretoko for back channel Sincerely, Damon ________________________ Damon Sicore 2008-08-13T15:50:20 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12274 [Followups aimed at mozilla.dev.planning] A number of folks have expressed interest in discussing full-text indexing solutions for the Mozilla platform. I'd like to propose that we have a phone meeting on Tuesday, August 19, 1:30 PM Pacific time. See https://wiki.mozilla.org/User:Dmose:Full_Text_Indexing_Meeting for all the details. Feel free to add items that you wish to discuss to the agenda, and if the proposed time doesn't work for you, please let me know! Dan Dan Mosedale 2008-08-13T00:37:44 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12271 Please note the new conference number: Details * 11:00am Pacific, 2:00pm Eastern, 18:00 UTC * Mozilla Building S * 650-903-0800 or 650-215-1282 x91 Conf# 8605 (US/INTL) * 1-800-707-2533 (pin 369) Conf# 8605 (US) * irc.mozilla.org #shiretoko for backchannel Hey everyone, As the astute will have noticed, the name of this meeting has changed slightly to be "Firefox / Gecko Product Delivery Meeting". We've been shifting the purpose of this meeting to talk about the scheduling and status of various releases. This week I'll be giving a bit of context about all the various Firefox releases we have going: - Firefox 2.0.0.17 - Firefox 3.0.2 - Firefox 3.1 The primary focus of the meeting will be Firefox 3.1, as it's the next major release and the thing which we need to talk about, but we'll go over the status of the other ones as well since as we parallelize development streams, people are more likely to be involved in multiple releases. Agenda to appear shortly at http://wiki.mozilla.org/Firefox3.1/StatusMeetings/2008-08-12 but today's topics will be: * status of Firefox releases * schedule risks & determination ** code status ** l10n status ** QA testplan status ** build status * feature status tracking * security reviews * roundtable (The Wednesday meetings will be more developer-centric, talking about the various development issues that need cross-component attention and sharing knowledge and experience to combat the challenges we face there) cheers, mike Mike Beltzner 2008-08-12T16:08:35 http://comments.gmane.org/gmane.comp.mozilla.devel.seamonkey/12243 I'm moving the 1.9 unittest master on qm-rhel02 to production- master.build.mozilla.org tomorrow morning. If any issues arise, please ping me in IRC or comment in Bug 450119. Thanks, Lukas lsblakk 2008-08-11T17:56:58 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.mozilla.devel.seamonkey