Continuous Integration

Release Schedule

May 2020
S M T W T F S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Branches

Twitter

Simply ship. Every time.

What happens on your PC… should stay on your…

04/29/2007

Astute IRCers may have noticed I’ve been on vacation. I’m now home, chillaxing1 after having spent a few sunny days in Las Vegas.
It was my second time visiting the City of Lost Wages. I met up with a friend from the right coast and a couple more (local) friends joined us the next day.
This trip was more fun than last time, I think mostly because we did things other than gambling this trip around. We visited Hoover Dam2 in addition to actually going to see a few shows.
I think my favorite was La Reve, but we also saw Blue Man Group, which was unexpectedly engaging and fun. We also randomly happened to catch Penn & Teller, an act whom it’s hard to go wrong with.
Being the plane geeks that we all are, we also spent the last night at the pricey3 MGM Grand, with room overlooking KLAS’s one-eights.4
We also sampled a bunch of buffets. The Bellagio’s, while somewhat pricey, still stands as the King of Buffets. (Never eat at The Trop. You’ve been warned. In fact, you’re better of ignoring, for the purposes of visiting Vegas, that the whole hotel exists.)
I also learned how to play blackjack in not an entirely lose-all-your-money manner. The first time I was in Vegas, I was a bit too intimidated to sit down and be required to interact with a real dealer. This trip, I learned that some dealers can be jerks, but for the most part, they’re generally nice. I suppose I should’ve expected this, since you’re basically there to give them all your money… and it would behoove them to be not-jerks.
In one of the hotels we stayed in, there was a big scary sign about removing items from the mini-bar; one of the friends who showed up the next day didn’t read the sign, and started pulling a bunch of things out of the bar to inspect what type of booze-ahol they were, and then put them back. “Ooops.”
At one of the friendlier blackjack tables, one of the players was asking what we all did. I mentioned I worked on Firefox, and he said he’d heard of it, but—once again—asked why he should use it.
I don’t know if it was because of the free drinks or because I was up a few hundred bucks at that point, but I… remembered my friend digging through the hotel room minibar and spouted what I think would make a pretty good new slogan:



I’m sure pkim and cbeard will love this5

The whole table couldn’t stop laughing. Hopefully that’ll turn into a couple new users.
Since I did not hit the $16.8 million Vegas BucksTM jackpot, nor make a million playing table blackjack, I will be back, reading email and on IRC tomorrow.
__________________
1 As the youngins these days call it
2 “For all your dam needs!”
3 But actually worth it
4 I’m the one in the picture in the chair, with the martini, operating the radio. Obviously.
5 Lamentably, I am without camera. Still. So Lee L (??) provided this image, via Google Image search.

Head in the Clouds, Foxtrot

04/20/2007

Gen linked me to a recently posted article detailing an old interview from November, 2005 with Google’s Eric Schmidt.
It was a great read, but Gen brought it to my attention for a specific reason1:

Wired’s Vogelstein: You’ve talked before about how flying your own jet helps you manage. Explain. The reason I’m intrigued by it is because the only other guy I know who flies a jet is (Oracle boss) Larry Ellison. But you can look at Larry Ellison and understand how the machismo associated with flying a jet translates into Oracle’s culture. I don’t get that same sense of machismo talking to you about flying.
Schmidt: It’s helped me in the following sense. The difference between what I do normally every day and flying a jet is that when you are flying a jet people can actually die—right now. So while it’s very hard for any actual human harm to come in this hour with you, when you fly a jet that’s very possible.
And so in the jet training, and they do this whole thing called cockpit resource management, CRM, there’s a whole protocol about how you handle life and death matters, what are the rules, and people pay attention and you would too obviously. I mean, it’s a natural human thing. And by the way, people who don’t pay attention don’t pass, they literally fail them.

And the other rule, and this is particularly true in difficult training situations, is it’s “What’s next, what’s next, what’s next, what’s next.” Your eyes have to be constantly moving, and literally to the second.
And the problem, of course, is at the end of this you’re very tired, but I think it’s a reasonable metaphor for high tech management. The moment you let your eyes relax, there’s something else coming. And by the way, it’s okay for you to say you don’t like that, but if you don’t like it, then you can’t succeed in it.
So we’re always on. Everyone is on their e-mail 24 hours a day, you know, people work at midnight on a Saturday night, that kind of thing, and it’s expected.

Me being… well… me, I find his analogy interesting and, of course, apt… except for one aspect, which I think is not only a false analogy, it turns out to be an extremely dangerous one.
[This is the part in the post where I'd normally go to a cut, but I think this is a relevant issue,2 so I won't for this episode.]
In his answer, Schmidt accurately describes the pressures related to preparing for and executing proper Cockpit Resource Management during a flight; as he says, life is faster in a jet, but CRM is something even us lowly piston-pilots have to take into account on every flight3.
I think Schmidt does a great job of trying to convey the attention it takes to focus and fly with proper CRM; the way he describes it, it makes me believe he’s referring to The Scan, which I can attest to from experience can be tiring from flying by for as little as half an hour4. Even flights on severe clear days, I’ve often come home and fallen right into bed.
Where his analogy falls apart is his conclusion: “So we’re always on. Everyone is on their e-mail 24 hours a day, you know, people work at midnight on a Saturday night, that kind of thing, and it’s expected.”
Now, how many of you would want to get on a plane at midnight on a Saturday, flown by pilots who’d be up flying since 8 am?
Any takers?
Yeah, me either.
I obviously don’t know under which rules Schmidt flies his jet, but commuter and “on-demand” operations—your standard chartered flights— are governed by part FAR Part 135, which specifically limits the amount of flight time a pilot can have in a year (1,400 hours), a quarter (500 hours), and two consecutive quarters (800 hours).
The regulations go into further detail about how much time a pilot must “rest” for before they can return to flying duty. FAR 135.267 has all the gory language for unscheduled 1-2 pilot crews.5,6
This may seems common sensical, but what I find particularly interesting about the issue is there have been a number of recent7 rulings that require carriers to include “reserve duty” against the limits: “We have consistently stated that reserve duty is not rest when the reserve flight crew member must maintain accessibility (via telephone or pager/beeper) to the employer and there is a present responsibility to work.”8
So describing our industry as “So we’re always on … and it’s expected” is an awful analogy to being a (safe) pilot. If you interpret the analogy to be to “a pilot responsible for the safety of his ‘airplane’9 and ‘those on board’10, it’s factually incorrect.
Another concept taught to pilots starting during the initial rating11 is a concept called Aeronautical Decision Making.
It’s the FAA’s fancy way of describing the part of being a pilot that says “You know what? I only got three hours of sleep and I haven’t had anything to eat in the last 8; maybe flying a plane isn’t the best thing for me to be doing right now.”12
Obviously, when hacking on code, the decisions (typically) aren’t life-or-death. But the law of (quickly) diminishing returns still applies.
I don’t buy the (implied?) supposition that “being on” at “midnight on a Saturday,” and generally 24 hours a day, seven days a week, holidays included, makes you a better decision maker.
Or a better leader.13
I can’t imagine it particularly enhances one’s ability to execute.
Buuuuttt… I’m not the CEO of the most successful company this generation. I’m not a CanythingO… or, heck, even a businessperson for that matter.
I do know one thing, though: it certainly doesn’t make you a better pilot.
_____________________
1 Which I actually didn’t know about Schmidt…
2 Which I’ve pontificated on before.
3 So it turns out that you fall out the sky at the same 9.8 m/s whether you’re in a Cessna or a Gulfstream…
4 I’m told, however, that like running, it’s a skill you build a tolerance up for.
5 FAR 135.265 has (even stricter) dutytime/rest requirements for scheduled operations.
6These sorts of rules exist for air carrier operations as well, but of course they’re covered by a different FAR, Section 121.471.
7 In the last decade.
8 Quoted from a 1999 Department of Transportation ruling on the matter.
9 “Company.”
10 “Employees?” “Shareholders?”
11 And reviewed heavily during most BFRs and safety seminars.
12 A surprising number of pilots lack this little voice of preservation in their heads, and I think we all tell it to shut up from time to time, with varying implications on safety.
13 Confusing human beings for the baremetal in your data center seems… problematic to me.

The Branches That Bind

04/19/2007

(Crossposted1 to mozilla.dev.planning, mozilla.dev.builds, mozilla.dev.apps.camino, mozilla.dev.apps.calendar, mozilla.dev.apps.seamonkey, and mozilla.dev.apps.thunderbird).
rhelmer and I have recently been discussing the release process as it relates to tagging and retrieving source from the CVS repository for Firefox and Thunderbird releases.
The way we do it now has a lot of historical vestiges and the policy was crafted around some assumptions that aren’t really valid for the project and the way Firefox and Thunderbird (and other projects in the Community) use the repository these days.
So we’ve come up with the following proposal we’d like feedback on.
The Proposal
When code complete is reached for the current Firefox release milestone, a release branch will be cut. The standard FIREFOX_version_RC1 and _RELEASE tags will be applied, but to a MOZILLA_datespec_RELBRANCH branch that will replace the venerable FIREFOX_version_MINIBRANCH. This _RELBRANCH tag will be applied to the same files the _RC1 and _RELEASE tags have traditionally been applied to.
If respins during the release are required, developers would check the fixes into the relevant (1.8/1.8.0) branches, as always; they could then either check the code into the _RELBRANCH themselves, or we can take care of that, whichever is easier. When the code for the candidate is ready, the next _RCn tag will be applied and the _RELEASE tag will be moved.
Rinse and repeat until the release is shipped.
Any equivalent Thunderbird release (if one is required) will come off of this branch as well. (This is why the suggested name is MOZILLA_datespec_RELBRANCH and not something like FIREFOX_version_BRANCH; products other than Firefox could come off the branch, and versions other than version could come off the branch.)
This branch will then die at the end of the release cycle.
This may be hard to visualize, so I took the liberty of adding it to our beloved branching diagram:2


The Reasoning
Currently, we apply _RCn and _RELEASE tags to the relevant development branch (i.e. MOZILLA_1_8_BRANCH) and then add _RCn tags and move the _RELEASE tag as we respin candidates. This process must be undertaken with extreme care, and while we record information when we perform the operations against the repository, because CVS does not version tag operations, that information is lost to external consumers of the source coming out of CVS (this is why we tag the _RCs individually; to track these changes).
Creating a release branch to isolate and record any changes required for a specific release is a long standing release engineering best practice. In the Mozilla Project’s case, it will allow us to record the changes we make during a particular release cycle and isolate changes so that we are able to assert exactly what went into a release.
Additionally, it will make security firedrills significantly easier: the release branch can be revived at any point in time to release a fix to a particular security issue, so we can assert that a particularly release is the previous release with *only* the required security changes, an issue we’ve run in the past.
Finally, it will (admittedly, for me) simplify the release automation’s respin support; the automation can now just track the _RELBRANCH, as opposed to attempting to fake branching by moving tags around on the regular development _BRANCHes.
The Impact
The impact to developers is quite low. In the worst case, those landing post-code complete fixes (fixes to a release candidate) will have to pull a branch to land their changes. In the best case (if a release engineer merges the change, which is TBD, but quite possible), then developers will not be impacted at all.
The impact to other projects relying on the Gecko milestone changes as well as any other consumer of Firefox-related source code should nonexistent; the _RCn and _RELEASE tags will, from an external perspective, still exist and pulling them will do the “expected thing.” We have discussed, at some point, forgoing application of the _RELEASE tag until a particular _RC is declared to be the final release, but this would really only impact consumers of the source tarball who pick up the RC tarball.
In terms of the repository, it is the case that one extra tag per release will be applied to all the files; the _MINIBRANCH will be replaced by the _RELBRANCH, so for the four files that were tagged with the _MINIBRANCH, they will have the exact same number of tags.
The Upshot
We’re planning on implementing this change for the upcoming Firefox 2.0.0.4 release, so please discuss and let us know if you have any questions or concerns.
______________________________
1 Read: “spammed”
2 Sorry in advance for the unwieldy size.3
3 Click to enlarge!

Version Control System Shootout Redux Redux

04/12/2007

Late last year, as the Mozilla project began looking at the tools we’d need for the Mozilla 2 development effort, it became clear that trusty ol’ CVS, while carrying the torch for so long, would not meet our requirements for ground-breaking development.


Mortal Kombat II, Version Control Edition: The Prologue

At the last Mozilla Summit, we all met in a session and were able to narrow down the choices to two contenders for consideration: Mercurial and Bazaar.

Brendan’s merge requirements bring all the version control systems to the yard, and they’re like “It’s better than yours…”

We were able to narrow down the decision quickly because the type of development Mozilla 2 will require dictates a model that differs from CVS in ways that systems that attempt to emulate that working model, like SVN, would not work well for us. We turned our attention to the big names in open source distributed systems: Git, Mercurial, Bazaar, and Monotone.
While they’ve made recent progress, Git was lacking in Win32 support and it was unclear that this would ever change and if it did change, it was unclear that Git-on-Win32 would ever become something more than a second-class citizen. As good, performant Win32 (and Mac and Linux) is a hard-requirement, Git lost in early Kombat rounds. This is unfortunate because (as we would soon find out), lots of issues with the other systems did “just work” in Git.
Monotone was ruled out relatively early as well, due to the similar Win32 performance issues and not wanting to split developer resources with Monotone fix- and feature-requests.
At first, this left Mercurial standing in the ring. Ahh… at last, a simple Mozilla project decision.
But then, during the version control discussion at the Summit, Bazaar was brought up. It had a decent set of features that sounded interesting and useful to us.
We started investigating. And suddenly, there were two.
[Insert a quarter to continue...]

Read More

Head in the Clouds, Echo

03/31/2007

I was looking for a specific air traffic control clip (more on that later), but I randomly found this clip of KJFK Ground Control.
It’s kinda long (12 minutes), but it’s got tons of great lines; highly amusing.
Upon hearing it, a friend said the New York accent makes it all the better.
There are a couple of points in the clip where I just expected him to blurt out: “I can’t f@#*(! make my mind work…,” ala Winnebago Man.
“We’ll visit you in the duty free…”1
Definitely recommended.
________________________
1 Makes you wonder: can you bribe ground controllers the same way you can bribe build engineers?

The Return of the Wired Build Engineer

03/27/2007

Over a month ago now, I blogged about the… “hilarity” that ensued when I moved into a (pretty nice) new apartment that… had no Internet (or cable, for that matter) connection to speak of.
In the ensuing month+, I’ve learned the following things:

  • My apartment turned out to be the only apartment in the entire F#!(*!!9#% complex that didn’t have a cable connection. Go figure.
  • Google Wifi is… ok. But you can’t really rely on it too much. I think it only worked a few times because there were low clouds, or something, because it never really worked again after I blogged about it.
    On the other hand, I never got an external antenna, and I don’t assume it’s supposed to work from your bedroom.
  • Home owner’s associations move slowly.
  • Contractors that are “the cheapest bid” move even slower.
  • Drilling holes in concrete to run eensy-weensy wires through is fun!
    Oh wait, no… what’s the complete opposite of fun? Oh yeah… loud.
  • When you have no TV and no Internets, your DVD collection becomes relatively… important. And DVDs you had forgotten you owned become surprisingly interesting again!
  • Despite this, you can only watch so much [[QaF]] before… you just can’t really watch it anymore.
    I never thought I’d get there, but… here we are.
  • At some point, you start to care less about the “why” to the whole question about “wires being cut to your apartment in some painting/remodeling accident” and you start to care more about the “What the H&#@$! are you going to do about it in a not-six-month-timeframe?”-question
  • Planning a flight without innerwebs is hard. And has not-so-great results (in terms of less-pilot-stress; in terms of artistic beauty, the results were spectacular…)
  • When the innerwebs return to you after being gone for a month,

    It’s like I’m a teenager again, running pine on an OSF/1 box for the first time.
    And everything is new.

There’s probably something to be said for the fact that I haven’t really felt as “moved in” to this new place until this evening, when I could actually write email(s) from my couch. There’s probably something… pathological about that.
But for now, I’m going to bask in the niceness of it.
More as I catch up.
On everything.
(Interesting factoid: it literally took my computer at home some 30+ minutes to process my entire mailspool with spamassassin; and my computer is a 3 GHz Pentium 4, so it’s not like it’s slow. I also found about 10 emails that I hadn’t seen among all the spam. That’s… wow… in a depressing sort of way.)

The Return of “FS” Builds

03/09/2007

Some months ago now, I was trolling through the [[Build:Farm]] for some free space to run some then-critical builds, and I happened upon a set of Tinderboxen named “Firefox-FS.”
While looking at other machines, I found more of these “FS” builds. We ended up turning them off at the time, because it wasn’t entirely clear what they were, and it didn’t look like they were being used.
Well, that “FS” stood for “free software” and those were the builds of Firefox that were composed of completely free software (which tends to mean “no branding, no talkback, etc.”)
These builds were missing for some number of releases, but now they’ve returned, and we’ve added them to our release manifest.
We will provide these free software builds moving forward for the 2.x releases.
You can find them hiding out on ftp.m.o in the contrib/free-software directories.
You might notice there aren’t any Mac FS builds.
That would be bug 372859. (Now accepting patches!)
A big thanks to Coop, by the way, for reviving these builds and wrestling them to the ground for the 2.0.0.2 release. It was a lot of… not-entirely-pleasant work, shall we say, but he got it done.

March Madness

03/05/2007

Someone once told me: “[Your] release procedures are the most primitive and barbaric I’ve ever encountered.”
After thinking about it for awhile (and getting over the initial sting of the commentary), I came to a couple of conclusions:
First, the person providing the critique had limited experience with… well… a complicated release process, one that involves releasing builds in 40+ locales and delivering updates to the desktops1 of millions of users. This person did have a lot of experience with release processes that he had [the fortune] of being able to design (and implement!) himself, and therefore seldom had to address the issues related to legacy- and/or poorly documented-infrastructure that we must deal with every day2.
Second, in some very real sense, he’s right.
Our current release process, which is the fourth or fifth generation of, from what I can tell, is approximately the third or fourth mostly-completely-different version of a Release Process ™ that we’ve used. It is way more manual3 than it needs to be, has a number of especially-retarded-if-you-don’t-happen-to-know-the-history steps and provisions, encapsulates processes in unnatural-and-hard-to-understand ways, generally takes too long4, and requires an extreme amount of mostly-constant-while-it’s-going-on focus.
On the charitable side it… well… addresses the requirements necessary to release 40+ locales, on three major platforms, including automated updates, for… millions of users.
At the beginning of last October, rhelmer, after having done a number of releases, began looking at ways to automate the current Firefox/Thunderbird release process, warts and all.
He, along with help from others, have made great strides in creating a solid framework for handling the various steps involved in putting out a release. A great side-effect of his work is that it has put our release process—warts and all—into the public repository with all our other code, so others can benefit5… and hopefully contribute.
One of our goals for the month of March is to knit together the release automation so that we can realize the seemingly-never-to-materialize-mirage of complete, end-to-end automation.
To that end, we’re working towards that goal fully in the open, and as I made reference to last week, this is month for it.
I spent time today filing a bunch of bugs on the various issues we need to fix to get this to work, and made them all dependent on the tracking bug for this effort.
We also have a sorta-Joelish Google spreadsheet to help track the effort.
If you’re interested in grabbing one of the bugs or generally helping out with the automation effort, please feel free to mosey into #build.
I can’t promise that it will be the most glamorous work in the project, but it’s some of the most-used and -useful work, and it will be appreciated—even if indirectly—by… well… millions of users.
In 40+ locales.
On three platforms.
______________________
1 The issues involved with releasing desktop software are not entirely similar to those related to releasing web-only software; that’s not to say one is easier/better or harder/worse than the other, but rather that a lot of release engineers from my “generation,” shall we say, have very limited desktop release experience, becuase they’ve only worked for dot-coms, and thus they were focused on website/web-app pushes.
2 As bsmedberg asked me in #build last week, “that’s making things unhappy on msys… do you remember why it was necessary (shouldn’t be)” and my answer was something along the lines of “No I don’t, but I remember it was breaking something.”
3 Read as “requiring human intervention, thus burning through people as if they were crumpled newsprint”
4 As in wall-clock time
5 Or, at least see how the magic happens.

Head in the Clouds, Delta

03/02/2007

A lot of interesting things happen to you as a pilot at the 90-day mark of being stuck on the ground, both from a government/regulatory standpoint and a club standpoint.
The weather here has been pretty not-VFR for the last couple of weeks, and I’ve been getting antsy about the fact that I may be getting close to hitting the 90-day mark. I pulled my logbook the other day to find out when I last went up, and it was January 24th, for a Bay Tour (with mento, actually!)
I’m not even close to hitting the 90 day mark, but I’ve been on the ground so long, it feels like it’s been 90 days.
Yeah, I think it’s pretty clear I’m hopeless.
Fortunately, looks like I’ll be going up today, which is good, because I need to remind myself how to land.
(Surprising factoid: it turns out that finding yourself 1000 feet above a runway is a pretty good motivator to remembering [or figuring it out again], because… you’re coming down one way or another, eventually.)

***

In other IFR-training news, my instructor turned me into a cat last night.
That’s right, a cat.

Read More

([Mm]ozilla[^z]|[Ff]irefox|[Gg]ecko|[Tt]underbird)

02/25/2007

I made a post last week, ostensibly about my experiences with Google Wifi. It was actually about much more.

It had an umlaut in the title, so I wasn’t entirely surprised when it didn’t show up on Planet.m.o, thinking maybe foreign languages caused inter-Planetary indigestion.

After some debugging, we found that Planet’s parser was indeed crashing, but not on my blog.

I filed a bug to track the issue and within minutes—go go Gadget Mozilla Community—an… interesting configuration change was pointed out.

This change, which turned out to be the reason my post didn’t make its way onto Planet, raises a couple of important issues which, from what I can tell, haven’t really been raised or addressed heretofore:

The first is how editorial changes are made on planet.m.o, and how those changes get communicated, not only to those publishing to the feed, but to those reading it.

In my case, I was not notified that Planet’s seemingly de facto (and sole) editor, Tim Rowley, had added the filter.1 I’m not entirely sure how planet filtering works,2 so adding filters to my blog without telling me effectively removed my blog from Planet’s feed, because there’s no way I would know which “magical keywords” I needed to use to get my content onto Planet now.

In looking at the (admittedly short) planet.m.o config history, it looks like I’m not the only one who’s been silently censored: numerous people have been completely removed from Planet, without being given any notification or even a detailed explanation.3

In the bug, others have noticed community members’ blogs missing from the Planet feed, which begs the question: just how many blogs were removed because a single person decided the content contained in those blogs wasn’t what he (or his office4) was interested in reading?

It leaves me wondering “how much content, Mozilla-related, or otherwise am I missing from members of our community?”
The second obvious issue this raises is “What content is appropriate for Planet.m.o,” and, slightly related, “How do we enforce that content policy?”

Obviously, this is a fairly gray line, with lots of opinions on the subject.

For myself, I write about a myriad of subjects, which tend to fall into “very Mozilla-related,” “technology/web-industry related,” and “not-at-all Mozilla-related.”

Personally, I enjoy reading content on Planet that isn’t necessarily (or maybe not directly) Mozilla-related; I see Planet as a community resource that illustrates the Community—what its working on, what its interested in and worried about, its trials and successes, how it relieves stress, what big changes are happening in people’s lives that may affect the community—not merely the browser-and-related-projects and the code-that-goes-in-one-end and the bits-that-come-out-the-other.

Surely we could reduce Planet.m.o to a listing of fixed bugs and posts about what features we’re working on and when releases are available. But doing so would remove the human face of our work, sucking the humanity out of the Mozilla Project. A feed that lacks these elements would serve to imply that we’re all just a bunch of code-robots, hacking 24 hours a day, who don’t [need to] have families or hobbies, who don’t [need to] require sleep, and who don’t need to be treated like we have lives outside of our work on Mozilla.

Not only would that be a tragic and depressing face to put on our project, it would be an insulting one.

I understand that not everyone may agree with me, though. For my own part, I have often written about topics not particularly Mozilla-related. I’ve continued to write about these because I’ve received numerous comments on IRC and in person saying they really liked a particular post. Sometimes it’s been about why Digg and Slashdot users screw us. Sometimes it’s been about flying.6

To be clear, I’m not saying that a more open policy of content on a space like planet.m.o does not require some consideration and respect for the forum their content is being featured in. I take special care to my non-Mozilla related posts in the “extended post” section, making it easy to skip over if the first paragraph doesn’t grab your attention.7

In some cases, I try to use the same title, so it’s really easy to skip in the feed reader. This is not about forcing people to read content they don’t want to read. And you can be sure that if I’d gotten a couple of “Geez, man… stop with the stupid open letters“- or “I really hate your Gimp Art ™“-comments, I would’ve found another outlet for that particular content. But that hasn’t been the case.

In fact, it’s been quite the contrary.

Immaterial of the feedback from readers in the Community, I find myself experiencing a paralysis over writing anything now. It’s been communicated—without being given the respect of being emailed or otherwise talked to— that I’m “allowed” to write about Mozilla, Firefox, Gecko, and Tunderbird. I find myself thinking “Well, I don’t really have anything to say about those four specific topics. So I guess I won’t bother writing anything,” mostly for fear that this stuff really is boring and no one wants to read it.

That’s a [hopefully?] unintended chilling effect of someone striving for “a lightweight process,” but it nonetheless exists, and it’s not very pleasant.

I’m not exactly sure how we’re going to solve the problem; there are lots of possible solutions8, but I am sure of one thing: the silent filtering and dropping of content needs to stop.

The unilateral implementation of editorial policy that has not been discussed and is not posted anywhere needs to stop.

And the conversation about what’s appropriate for our community needs to be had, not avoided.
We’re the Mozilla Project; we have a history of doing better, and we can do better.

__________________________
1 But, being among only three people being filtered, I guess I’m in good company.
2 Does it filter subject titles? Tags? Posts? Blog comments? What? I actually spent some time Googling for this, and never did find a clear explanation.
3 In Pink’s case, it is especially ironic that every single post he’s made since he was removed for “very little Mozilla content” has been about Camino and/or Mozilla.
4 Pinkerton refers to a scary situation “when voices in the community can be turned off like a faucet at the whim of people at a corporation.” I think this is somewhat confusing, because when we talk about “a” or “the Corporation,” we’re typically referring to the Mozilla Corporation. Tim Rowey works for IBM, not MoCo.5
5 And I think it needs to be said: I have no doubt in my mind that there would be rioting in the virtual-streets if someone at MoCo were asserting this level of editorial control-without-input over a resource like Planet.
6 But if you read between the lines, it’s actually not, which is why people said they like it; it actually applied to the Mozilla project in a usually-tangential way.
7 Which, of course, turns out to make it a [useful] challenge for me, the writer, to grab your attention, using only a single paragraph!
8 This whole problems screams out for a solution addressed by that Web 2.0-ey concept of semantics; this seems like a solved problem, what with tags and feed readers that can filter, based on tags. I would gladly tag my posts with an agreed-upon tag, so that those not wanting the strictly-not-Mozilla-stuff could filter. In fact, I already do, but “blahblahblah” isn’t a very standard tag. ;-)

Newer Posts
Older Posts