<< previous meeting | index | next meeting >>
- Wednesday, May 23th, 16:00 UTC
- Phone meeting
- Join #calendar-mtg on irc.mozilla.org for attendance
- Toll free numbers
- US/Canada: 866-692-3163
- Netherlands: 0800-020-1392
- Germany: 0800-000-3441
- Participant Passcode
- Conference controls
- Press *1 private help menu
- Press *6 mute or un-mute individual line
- Each time you say something, please say your name first so people know who's speaking
- 0.5 status
- List of currently open blocker bugs
- Status of blocker bugs
- Post 0.5 planning
- What should we do with Joey's bugs?
- Asking Joey, ofcourse!
- There are some bitrotted patches, which might be valuable to take
- What should we do with Joey's bugs?
attendees: phillip, martin, simon, daniel, clint, matt
- 5 blockers
- Only one is holding us up at this point - the alarm bug 382840, mvl will do the review tonight
- The other bugs are simply "release" level items that will be addressed when we respin the RC2
- We need to also push the tag on all the L10N files that have changed.
- Matt will do this in just a few minutes
- Matt and Clint need to update his notes on the release preparation wiki page
- We need to checkin the version bump for the lightning wcap version number
- Maybe have a new RC tonight if we have a positive review.
- Once the blockers are out of the way we can make the next RC2 and hopefully it will be the final release
Post 0.5 Planning
- Mickey said last week that he would help with landing the outstanding patches
- Joey has no plans to work on calendar code again, he has moved on to Firefox and has very little extra time anyway.
- He will switch his reviews to other folks
- He has several bugs that are assigned to him with old patches that we probably want to take. Need to decide how to address them, unbitrot them and see if they are worthwhile
- Daniel says that folks need to look at these fixes and see if they have time to take these things. Everyone should have a look at the list and reassign to yourselves if you feel comfortable taking the patch on and completing it.
- Some of those were stuck because of philisophical issues that stuck patches, other patches were things that we didn't know if we wanted in the product
- Daniel will take a look at the list and take what fits for folks and we will leave this on the status page so that other people will grab things as they see fit.
- Don't want to assign the bug to yourself if you don't expect to work on it. Things that are assigned do need to show progress.
- Simon will reassign items with no patches back to "nobody"
- Landing items after 0.5
- We do want someone to watch the tree and coordinate the checkins after 0.5 so that we can ensure we don't get a build with 30 changes.
- We do need somebody to drive this so that we can make sure that patches do not conflict with each other.
- It doesn't necessarily mean that Mickey (or whoever) will have to check in everything himself.
- Simon will put together a list to show what patches will be going in when.
- Maybe we don't need a sheriff since folks can check bonsai for themselves, much discussion for either way.
- General Items
- We have two new components in bugzilla: preference window and one for build-config, if you see old bugs lying around that might be suitable for these new components, please feel free to reassign them.
- all the tinderboxes are mozilla's. the "cg" one doesn't have access to talkback and AUS. Chris Cooper is working on getting access to those items for the community. Once that is figured out, we can move back to the community tinderbox.
- To get universal binaries for Lightning we need to do some makefile hacking in order to make our builds build them by default. We could also automate the process we are currently doing in order to package them. None of the automatic stuff that makes universal binaries happens for lightning because lightning is an extension. We'd have to change things in order to make this work for extension.
- What of these "binary incompatibility" problems we've been seeing?
- We need to move all our code that uses compiled C to use only frozen API's that will help greatly to reduce these sorts of issues
- We have to do this because 1.9 gecko will no longer allow extensions to use non-frozen interfaces
- We have a bigger issue here too because the Thunderbird team is changing the entire project to frozen linkage on trunk, so that will break lightning on trunk until we switch to frozen linkage
- The guy with Fedora's Thunderbird is seeing a problem because he is using Fedora's thunderbird builds. Since the Fedora folks providing that thunderbird did not build it in the same way that tinderboxes build thunderbird.
- The sooner we can move to frozen APIs the better, we still need to do that
- These could be addressed by having third party folks ensure binary compatibility so that everyone uses the same binary builders and a standard set of libraries.
- It's a question about where to draw the line, you can either draw it at the build system level, or you can draw it at the interface level (frozen interfaces).
- Ause mentioned this binary compatibility idea to bsmedburg and it would solve some pieces of this problem.
- Daniel will bring up this binary compatibility idea to bsmedburg tomorrow.
- Ause got a solaris tinderbox up and running, should be going live soon. And that can report to the main sunbird tinderbox page).