In case people missed it earlier, Lukas setup 3 new disposable branches recently: Alder, Holly and Larch, in addition to the existing Birch, Cedar and Maple.
As we move to the faster release cadence, it seems like more and more people are working in their own project branches, and then landing everything when its all done. Very cool.
All these builds and tests take place on the shared pool of machines, so the results are the same. But keep in mind, whether a project branch makes sense for your specific project really depends on how many people are involved in the shared work, and how long that shared work is expected to take to complete.
Here’s the guidelines we’ve seen make most sense so far:
If it is one person, working by themself, then a user repo and Tryserver is typically enough.
If it is a group of people, working on a project for days/weeks/months, then a disposable branch makes most sense. Just edit this wiki page to claim a disposable project branch, and you’re ready within a few hours.
If it is a group of people, working on a project for quarters/years, then a new dedicated project branch makes most sense. File a bug with details from here, and you’ll have your shiny new dedicated project branch in 2 weeks.
Summary: To deliver Fennec5.0 betas starting 17may, the new plan is to backport Fennec code changes from mozilla-beta back to split repos and and ship Fennec5.0 betas from the split repos using existing release automation.
Details for the curious:
To ship Fennec5.0 on the same release cadence as Firefox5.0, on the consolidated repos on mozilla-beta, requires:
a) changes to release automation to handle consolidated repos
b) remainder of buildbot0.7 -> buildbot0.8 migration – to streamline release day mechanics.
These changes are on track for Fennec6, along with Firefox6, but we cannot get these changes into production before 17may, in time for Fennec5/Firefox5.
To ship a Fennec5.0 beta on the 17may date, the new proposed plan is to:
setup new mobile-5.0, mozilla-5.0 repos
for l10n, RelEng thinks we can point automation to the l10n/mozilla-beta repos.
for sanity check, RelEng will build an early Fennec5.0beta1 before 17may, to make sure this infrastructure works.
wait for the planned drop from mozilla-aurora –> mozilla-beta on 17may
have mfinkle/blassey merge code from mozilla-beta to new mobile-5.0 & mozilla-5.0 repos
have aki/lsblakk create Fennec5.0beta2…5.0betaN using existing release automation.
RelEng will make a staging Fennec5.0beta build next week to verify all this before 17may.
We will repeat this for every Fennec5.0beta until we get these automation changes live in production. Current estimate is early June. Whether we ship Fennec5.0 in this way depends on exact date the new automation is ready – to be revisited.
NOTE: While there are currently no Fennec4.0.x releases scheduled, it is important that we remain able to ship Fennec4.0.x chemspill releases if needed. This plan does not impact our ability to do Fennec4.0.1 chemspills.
I’ve seen Dave Eaves give a couple of presentations on/around this topic, and always enjoy his insights. This specific presentation is one that I had not seen before, but heard about from coop. Finding the full slidedeck along with audio recording was really great – I can now get my deaves fix without having to wait until next time he and I are at the same event together.
His informal presentation style, and sense of humour, helps keep you engaged in an uncomfortable “warm fuzzy soft skills” topic that many people in software shy away from.
Some highlights that stuck with me (in no particular order):
1) For any discussion, there are four main categories of communication:
* inquire
* paraphrase
* acknowledge
* advocate
** (Hint: if both sides are doing 100% “advocacy”, its not going to end well.)
** (Related hint: in order to persuade, you need to be open to persuasion.)
2) Don’t tell people how to do something, do tell people why you want something. This leaves it open for everyone to brainstorm whats the best way to implement something – which might turn out to be better/easier/faster then your initial idea.
3) Beware of miscommunications and mistaken assumptions in irc/email/bugs.
* 7-9% are verbal – the dictionary definition of words that you use
* ~38% are paraverbal (tone, accent, volume)
* ~50% are body language
4) Is an open source company a “software company” or a “community management company” ?
* what is the core competency? Code? Code+human communication?
** I think this is what makes it so hard to get used to working in an open source environment. And hence, hard to grow an open source community.
* Ideas are fragile; egos are fragile; You need a safe place in the community where people can suggest new ideas without being immediately shot down and discouraged. Without new ideas, you are dead but just dont know it yet.
David’s presentation is focused on open source community, which makes sense given it was at FSOSS. However, it feels just as relevant to a large closed-source organization or any environment where people who dont know each other well (yet) are trying to figure out a shared solution to a shared problem.
If you work with others, or work by yourself before coordinating all the different pieces with others, then this presentation is for you. Trust me. Watch it. Maybe its something you already know, and practice daily. Or maybe, like me, you’ll find yourself taking notes and wishing you could do-over some conversations.
(Why, oh why, didn’t they teach this in CompSci when I was in university?)
105 years ago today, at 5:12 a.m. in the morning, San Francisco got hit by “the big one”. The devastation is well documented here. The earthquake was bad, but the fires afterwards did most of the damage – a bad combination of broken gas pipelines causing fires, and most fire hydrants not working because of the broken water pipelines.
Just around the corner from my home is one hydrant that DID work. Because of this hydrant, refugees in Dolores Park were safe, and houses beyond this point were protected from the inferno, so the neighborhoods have lots of houses from before 1906. More details here. Nicknamed “the golden hydrant”, it gets a new layer of gold paint, and some flowers, in a ceremony at 5.12am every year on this day.
As part of the whole new rapid release cadence, the Aurora builds are “string frozen”, so localizers can safely use these Aurora builds when localizing the Firefox5.0 release. If you see any problems, with any of these localized builds on Aurora, please let me know, or even better, please file a bug.
For the curious, here’s what the Aurora about box looks like for Spanish (specifically es-ES):
For comparison, I note that the total population of Hong Kong is 7million, and San Francisco is 800,000. That is a *lot* of vaccinations – significantly more then all the war/earthquake/flood/disaster injuries they reported. Also in the list of medical procedures carried out in 2009 was “110,236 baby birth deliveries” – even in the midst of everything else, life goes on.
This in-car camera footage was taken during the rally in Tasmania a few days ago, and catches some mis-communication between the driver and the navigator. The car was doing 118mph (190km/hr) at the final corner.
How people behave, and treat others, when things go wrong is quite telling. In this case, you can hear the first “sorry” while the car is still airborne. Also, they keep working together, and checking on each other, all the way to the end. Nice to see.
Best quote: “You cleared (flew over) the first fence, second fence you went through sideways, and the third fence you went through sideways.”
PS: In case you wonder just how hard can it be to give pre-written directions in a car, here’s a snippet from last years Circuit of Ireland Rally where the driver/navigator team worked really really well together. Note:
the navigator reads out directions in a non-intuitive way. The driver is already
committed to the approaching corner, and has already been told what to expect around the corner. The navigator is telling the driver what to expect after the next corner.
the large LED display near the steering wheel shows 1…6 depending on what gear the driver is in. Green is normal, but red means the driver is running engine dangerously fast and should change gear. All other information is distracting, so is removed! This makes it hard to tell speed but you can get an idea how fast they are going by noticing the number of times the driver redlines the car in 6th gear.
Very early this morning, legneato merged over the code from mozilla-central to mozilla-aurora. This means FF5.0 is now on Aurora.
Anything that lands on mozilla-central after this point is destined for FF6.0.
We’re still working through lots of mechanical details (name changes on mozilla-central, l10n for aurora, channel changer impact, last minute updater bustage, figuring out tags, …), so please be patient. After all this is our first time doing this! However, with any luck, later today or maybe tomorrow, we should have stable FF5.0 builds on Aurora. (click here for details on the name “Aurora”)
Oh, and by the way, all this happened *without* closing the tree!
There have been several questions about the exact merge mechanics going from
mozilla-central –> aurora. While the specific problem is how to handle landing changes from mozilla-central into aurora, along with any possible changes already on aurora, I note that this can happen going from m-c –> aurora or from aurora –> beta or from beta –> releases. The general problem here is how to merge from an upstream repo that has changes into a downstream repo that has other possibly conflicting changes.
Many thanks to bz, catlee and ehsan for the great discussion over lunch last week. Let me know what you think, or if you see anything missing.
Never delete the aurora repo, we need the history.
Pull from m-c to a new head on aurora. Note exact changesets used, as this will be needed for next drop.
Query hg.m.o for list of changes since known changeset / tag of the previous drop.
Human needs to review list of changes since the last drop from m-c, and figure out which changes to bring forward, and which changes to throw away.
Use “hg transplant” to take the changes we want to bring forward and bring over to the new head.
Human needs to resolve any merge conflicts. Note: some specific files need careful human review of any changes, even if there are no merge conflicts. all.js, firefox.js, configure.in, mozconfig
Safety check:
Diff new-head-on-aurora vs m-c == list of all previous aurora backouts (smaller list?)
Diff new-head-on-aurora vs old-head-on-aurora == list of new code changes in m-c (bigger list?)
Mark the original head as closed, to prevent accidental landings on the wrong head.
Still having a hard time grasping the scale of the earthquake in Japan. Most of the news in California is focused on the nuclear power plants at Fukushima, but the following struck me about the earthquake:
Its great to see Wikipedia and GoogleCrisisResponse spreading timely information, which is really important in situations like this.
This is two weeks later.
We get earthquakes here too, which raises the question: if an earthquake happened here in the bay area, could you be fully self-sufficient for at least 72hours? San Francisco Dept of Emergency Management has setup http://72hours.org to help people prepare.
UPDATED: added today’s story about the dog. Searching building wreckage is dangerous, more so when its floating at sea, so I’ve lots of respect for the people continuing to do this day after day. joduinn 02apr2011.
RSS
Doctors Without Borders / Médecins Sans Frontières
