Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What gets landed for FF5?

294 views
Skip to first unread message

Mike Shaver

unread,
Mar 22, 2011, 12:21:32 PM3/22/11
to L. David Baron, dev-tree-...@lists.mozilla.org, Ehsan Akhgari, dev-planning@lists.mozilla.org planning, Stuart Parmenter
On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron <dba...@dbaron.org> wrote:
> In the proposed model at
> http://people.mozilla.com/~sayrer/2011/temp/process.html , we'd have
> six weeks of development time for each cycle (without any freeze
> preceding it for people to buffer up work).  If we guess that the
> average developer has been done with Firefox 4 work and working on
> post-Firefox 4 work for about a month, that means that first pull
> from mozilla-central to firefox-experimental should be in about two
> weeks.

Possibly heretical: does the whole current backlog of changes need to
land for FF5? Even if they don't get in until FF6 (Sep 22, 2011 I
believe), that's still half the time that many of them would have been
expected in the previous release model.

risk/reward isn't something that's only for the end-game.

Mike

Mike Beltzner

unread,
Mar 22, 2011, 12:24:36 PM3/22/11
to Mike Shaver, dev-tree-...@lists.mozilla.org, Ehsan Akhgari, dev-planning@lists.mozilla.org planning, Stuart Parmenter, L. David Baron

+1 for this particular form of heresy!

I think that preference should be given for things that:

- have proven performance wins, and benchmarks that allow us to continue to monitor them,
- have easy killswitches so we can disable them if they cause problems,
- have high demand from the web development community (ie: text-overflow:ellipsis),

But I also think that we should be taking things on mozilla-central that we know about, instead of just opening it up for any checkin.

cheers,
mike

Boris Zbarsky

unread,
Mar 22, 2011, 12:29:55 PM3/22/11
to
On 3/22/11 12:24 PM, Mike Beltzner wrote:
> I think that preference should be given for things that:
>
> - have proven performance wins, and benchmarks that allow us to continue to monitor them,
> - have easy killswitches so we can disable them if they cause problems,
> - have high demand from the web development community (ie: text-overflow:ellipsis),

Please add:

- Patches from people who are not paid to work on this thing.

Seriously. Our story for non-employee patch contributors in the new
world so far is sad-looking. Note that I assume that employees are
working on things which are high priorities for us, so that new
contributors will by default start with things that are lower priority.
You may wish to quibble with this assumption, of course.

-Boris

L. David Baron

unread,
Mar 22, 2011, 12:34:13 PM3/22/11
to Mike Shaver, dev-tree-...@lists.mozilla.org, Ehsan Akhgari, dev-planning@lists.mozilla.org planning, Stuart Parmenter
On Tuesday 2011-03-22 09:21 -0700, Mike Shaver wrote:
> On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron <dba...@dbaron.org> wrote:
> > In the proposed model at
> > http://people.mozilla.com/~sayrer/2011/temp/process.html , we'd have
> > six weeks of development time for each cycle (without any freeze
> > preceding it for people to buffer up work).  If we guess that the
> > average developer has been done with Firefox 4 work and working on
> > post-Firefox 4 work for about a month, that means that first pull
> > from mozilla-central to firefox-experimental should be in about two
> > weeks.
>
> Possibly heretical: does the whole current backlog of changes need to
> land for FF5? Even if they don't get in until FF6 (Sep 22, 2011 I
> believe), that's still half the time that many of them would have been
> expected in the previous release model.
>
> risk/reward isn't something that's only for the end-game.

I think the current backlog should still be under the "normal six
week cycle" amount of changes, so I don't see the value in delaying
things to the next cycle. I could understand the argument that some
things shouldn't land *at all* because of the risk (but hopefully,
for the most part, that's not the sort of thing people are working
on) -- but I don't see why you'd suggest that they're not safe for 5
but fine for 6.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Mike Beltzner

unread,
Mar 22, 2011, 12:34:38 PM3/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
I intentionally did not say that we'd only take patches from employees. We'll take patches from everywhere as long as we understand the effect and the value. To imply otherwise seems odd, to me.

cheers,
mike

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Boris Zbarsky

unread,
Mar 22, 2011, 12:41:04 PM3/22/11
to
On 3/22/11 12:34 PM, Mike Beltzner wrote:
> I intentionally did not say that we'd only take patches from employees.

Yes, I know. What I'm saying is that we should give preference to
patches from non-employees. Your list was a list of patches to give
preference to; I suggested an addition to it.

I understand that if some random contributor shows up and writes a patch
we really want we'll take it. That's obvious. I'm saying we should
take the patch even it doesn't fall into one of the three buckets you
list it, purely because it helps us grow our community. That's assuming
we want it at all, of course; if the patch is not desirable that's a
different matter. But that gets handled at review-time.

> We'll take patches from everywhere as long as we understand the effect and the value. To imply otherwise seems odd, to me.

I'm saying that we should consider as part of the "value" of a patch
whether it helps us grow our set of contributors.

-Boris

Mike Shaver

unread,
Mar 22, 2011, 12:49:46 PM3/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Tue, Mar 22, 2011 at 9:41 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I'm saying that we should consider as part of the "value" of a patch whether
> it helps us grow our set of contributors.

I think that's a good idea. I might go so far as to make it someone's
job on a rotating basis, like sheriffing (but over a longer period).

Mike

Mike Beltzner

unread,
Mar 22, 2011, 12:54:41 PM3/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
----- Original Message -----
> I'm saying that we should consider as part of the "value" of a patch
> whether it helps us grow our set of contributors.

In my experience contributor growth comes from positive interactions in helping people understand what will help a patch get accepted and streamlining them into projects that could use their time and attention.

cheers,
mike

Mark Banner

unread,
Mar 22, 2011, 1:00:57 PM3/22/11
to
On 22/03/2011 16:24, Mike Beltzner wrote:
> I think that preference should be given for things that:
>
> - have proven performance wins, and benchmarks that allow us to continue to monitor them,
> - have easy killswitches so we can disable them if they cause problems,
> - have high demand from the web development community (ie: text-overflow:ellipsis),
>
> But I also think that we should be taking things on mozilla-central that we know about, instead of just opening it up for any checkin.

I know the release processes are changing, and this is probably just a
one-off for FF 5, but I think that if something gets pushed out as not
landing in the current release that is being worked on, it should be
able to be landed in the next release after that regardless of priority
of work.

Otherwise, I can see low-priority, small pieces of bug fixes, getting
forever pushed out and never landing. We also need a way to actually
flag that something has been pushed out and handle it in the next
release (rather than just rely on people using the right whiteboard
words or finding somewhere to land it).

Standard8

Ehsan Akhgari

unread,
Mar 22, 2011, 1:01:27 PM3/22/11
to Mike Beltzner, L. David Baron, dev-planning@lists.mozilla.org planning, dev-tree-...@lists.mozilla.org, Stuart Parmenter, Mike Shaver
On 11-03-22 12:24 PM, Mike Beltzner wrote:
> ----- Original Message -----
>> On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron<dba...@dbaron.org>
>> wrote:
>>> In the proposed model at
>>> http://people.mozilla.com/~sayrer/2011/temp/process.html , we'd have
>>> six weeks of development time for each cycle (without any freeze
>>> preceding it for people to buffer up work). If we guess that the
>>> average developer has been done with Firefox 4 work and working on
>>> post-Firefox 4 work for about a month, that means that first pull
>>> from mozilla-central to firefox-experimental should be in about two
>>> weeks.
>>
>> Possibly heretical: does the whole current backlog of changes need to
>> land for FF5? Even if they don't get in until FF6 (Sep 22, 2011 I
>> believe), that's still half the time that many of them would have been
>> expected in the previous release model.
>>
>> risk/reward isn't something that's only for the end-game.
>
> +1 for this particular form of heresy!
>
> I think that preference should be given for things that:
>
> - have proven performance wins, and benchmarks that allow us to continue to monitor them,
> - have easy killswitches so we can disable them if they cause problems,
> - have high demand from the web development community (ie: text-overflow:ellipsis),

This means patches with any of these properties, right? Does that mean
that patches which can be backed out are OK to land?

Cheers,
Ehsan

Boris Zbarsky

unread,
Mar 22, 2011, 1:03:13 PM3/22/11
to

Yes, but that's the second step. The first step is for them to not get
frustrated...

And one other thing. We _want_ some work on things that are "not a high
priority" to happen. That's how polish issues get fixed....

Either that, or we need to change our prioritization to include things
like "make X less buggy", not just "implement Y".

-Boris

Mike Beltzner

unread,
Mar 22, 2011, 1:10:57 PM3/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
----- Original Message -----
> And one other thing. We _want_ some work on things that are "not a
> high priority" to happen. That's how polish issues get fixed....

I think polish issues and bugs need to be considered high priority.

> Either that, or we need to change our prioritization to include things
> like "make X less buggy", not just "implement Y".

Yes, absolutely.

cheers,
mike

Steve Fink

unread,
Mar 22, 2011, 2:29:05 PM3/22/11
to dev-pl...@lists.mozilla.org
On 03/22/2011 10:10 AM, Mike Beltzner wrote:
> ----- Original Message -----
>> And one other thing. We _want_ some work on things that are "not a
>> high priority" to happen. That's how polish issues get fixed....
> I think polish issues and bugs need to be considered high priority.

For external contributors, at least early-stage ones, I think priorities
should be low priority.

From an external perspective, Mozilla is already a difficult project to
contribute to. Let's compare: several years ago, I wanted to use ltrace
to see into the data structures that were getting passed into library
functions. I'd never hacked on ltrace before, but I wrote a rather large
patch that screwed with some fundamental assumptions in the existing
code base. I submitted it to the project mailing list, and got back
feedback that it looked good but was breaking tests on some other
architectures, in particular ia64. I spent a weekend learning enough of
the ia64 ABI to fix it up, and used HP's TestDrive system to try it out.
Eventually, I got the test suite in no worse a shape than it was before
I started messing with things. The patch was accepted and committed.

In essence, I was able to get hacking on the code immediately, and was
willing to go to a lot of technical/development effort in order to get
my patch in. It wasn't a completely smooth nor fast process, but it was
straightforward.

At Mozilla, a contributor with an itch to scratch has to download a
massive wad of code, figure out MDC well enough to find and follow the
idiosyncratic build instructions, find and learn the basics of b.m.o,
and then begin researching the not-so-basics of b.m.o. and our
submission process. Contributor agreement. Reviews, and how to request
them via bmo. Discovering that a nontargeted r? will be ignored for a
decade or two, so then figuring out who to request a review from.
(Warning! People involved! Say goodbye to some proportion of technically
qualified contributors who are unwilling to engage with yet another
unfamiliar community, or too shy, or whatever.) Learn about irc, which
seems quaint to some, and our particular channels and their etiquette.
Or use blame logs, or trawl bugzilla for related bugs. Then there's
[checkin-needed], project branches, tree-watching, and starring to
contend with.

That itch had better be really irritating! I never would've made it that
far. In fact, I didn't -- I had one or two ideas that I started to work
on in the Mozilla code base back then, but I didn't make it through the
gauntlet.

Those are just the basics that we are currently willing to accept to
keep a large and complex code base under control. Now we add in
approvals, and/or a bewildering array of blocking/wanted flags. We want
these external contributors to gate their work on *our* priorities?
Contributors are volunteering to improve the Mozilla code base and
resolve an itch in something they use, and perhaps get bragging rights
and warm fuzzies in exchange. They are *not* volunteering to be Mozilla
worker bees, implementing the vision of Mozilla product managers.
Product management is enormously valuable, but I don't think it's on the
path to acquiring skilled external contributors. Even if product
management has a broad and flexible view of what changes we need, and
can describe that vision in a clear way that motivates people to work to
achieve it.

That's my long-winded way of agreeing with bz. External contributors
should have a greased path into the repository, and we need to be
willing to accept a fair degree of churn from low priority changes
purely to make such people happy. If we need additional barriers to
reduce destabilization or bloat, then I would propose that we try to
make those barriers technical and objective. For example, we could say
that any significant patch requires either approval *or* a comprehensive
test case. (Or evidence for lack of perf/size impact, or whatever.) The
policy should be spelled out up front as much as possible.

Anything where a contributor can work to resolve the problem
independently is fine. Anything dependent on other people is
demoralizing, because as a contributor you know that all of your hard
work can be scuttled if someone decides they don't like it (or doesn't
find it important enough on his/her priority list). Why go to the effort
if the risk is not under your control?

We don't need (more) sociopaths on the project, but we do need skilled
developers who aren't necessarily great negotiators.

Jeff Hammel

unread,
Mar 22, 2011, 2:59:37 PM3/22/11
to dev-pl...@lists.mozilla.org
I've only been here a year (though have been involved in OSS for a bit
now), so take this for what its worth, but I completely agree with
this. I heard it suggested before of a mentoring program for community
members. Why not tie these ideas together? Have either a dedicated
outreach team and/or whoever is interested (though preferably having it
considered part of their job instead of just an extra) help guide
contributed patches (that are worthwhile) to completion. Some people
will be hard to work with and we shouldn't throw excess energy at them.
But some people will get into it. They'll learn our processes and may
even get excited about contributing more. And we'll (re)learn the things
that make contributing hard and, hopefully, take these lessons to heart
and make things smoother.

Just my $0.02

Jeff Hammel

Joshua Cranmer

unread,
Mar 22, 2011, 4:51:01 PM3/22/11
to
On 03/22/2011 02:29 PM, Steve Fink wrote:
> At Mozilla, a contributor with an itch to scratch has to download a
> massive wad of code, figure out MDC well enough to find and follow the
> idiosyncratic build instructions, find and learn the basics of b.m.o,
> and then begin researching the not-so-basics of b.m.o. and our
> submission process. Contributor agreement. Reviews, and how to request
> them via bmo. Discovering that a nontargeted r? will be ignored for a
> decade or two, so then figuring out who to request a review from.
> (Warning! People involved! Say goodbye to some proportion of
> technically qualified contributors who are unwilling to engage with
> yet another unfamiliar community, or too shy, or whatever.) Learn
> about irc, which seems quaint to some, and our particular channels and
> their etiquette. Or use blame logs, or trawl bugzilla for related
> bugs. Then there's [checkin-needed], project branches, tree-watching,
> and starring to contend with.

So, just for kicks, I decided to figure out what a potential contributor
might have to go through to build their very own first version of
Mozilla Firefox.

I started by Googling for "Firefox source code", and selected the first
link, because it looked nice and relevant. This was, at least for me,
<https://developer.mozilla.org/en/download_mozilla_source_code>. Well,
if I wanted to write a patch, I probably need to use the source control
repository, which I am informed is CVS (although I am linked to
Mercurial pages for downloading). The example links use an ancient
2.0.0.4 as their base, and the prose takes a rereading for me to figure
out how to download the brand new 4.0 release.

I downloaded the 4.0 tarball, and unpack it, and notice that it unpacks
into a mozilla-2.0 directory instead of the standard firefox-4.0 that I
would have expected. Seeing that it has the standard configure file, I
run ./configure && make, and am greeted by the error that I didn't
specify --enable-application=APP. To fix this, I go back to the page,
down a few levels of links, which now tell me to get the source from
Mercurial. Assuming that the source build is still roughly the same, I
just copy-paste the links and try running it again, failing the
configure since I don't have the necko wifi headers. Trying to figure
out how to just --disable-necko-wifi takes a few more pages to find that
I need to add `ac_add_options --disable-necko-wifi' to my mozconfig.

So, just to build Firefox required looking through about 6 pages of
information, some of which is either confusing or contradictory. There's
no README in the build directory to even indicate that the build process
is much more involved than "./configure && make && make install", let
alone allow the lay user to figure out all that needs to be done.


I vividly recall my first patch. Just building a copy of Thunderbird
took around a week, although that was much due to the inadequacy of my
machine at the time as anything else (I didn't know I lacked enough
memory to build it). I think I mostly managed to figure out what needed
to be changed rather quickly, although I did require handholding to
actually make the changes. And then came the reviews. Having had enough
handholding in IRC by this point, I was told from whom to ask review;
and the reviewer actually granted the review pretty quickly. The
superreview, on the other hand... two months later, I redid a patch with
another superreviewer. When that was eventually sr+'d, I then got to do
the checkin-needed process (this was something I was already acquainted
with from another patch).

Perversely, the only reason I knew how to get my patch committed was
because I had to bear enough handholding that I became familiar with the
process by the time it got to that point. Anyone who wouldn't have
needed the handholding (my first patch ended up requiring massive
changes to underlying guts in Thunderbird code) would be lost when it
comes time to actually submit their changes. And I might add, this was
all in mailnews code, where the underlying approval levels needed are
much fewer than the current or proposed requirements for m-c (r, sr if
large enough, approval, blocking/wanted, multiple source repositories,
etc., etc., etc.). In fact, even though I do a fair amount of mailnews
work, I still don't like trying to get a patch into core Mozilla code;
what hope does a complete neophyte contributor have?

Paul Biggar

unread,
Mar 22, 2011, 5:46:14 PM3/22/11
to Joshua Cranmer, dev-pl...@lists.mozilla.org
On Tue, Mar 22, 2011 at 1:51 PM, Joshua Cranmer <Pidg...@verizon.net> wrote:
> On 03/22/2011 02:29 PM, Steve Fink wrote:
> So, just for kicks, I decided to figure out what a potential contributor
> might have to go through to build their very own first version of Mozilla
> Firefox.

I concur with this. When I started working on SpiderMonkey, it broke
all my expectations, and I was surprised with how difficult and
frustrating it was to get started.

So I tried to fix it, by writing this:
https://wiki.mozilla.org/JavaScript:New_to_SpiderMonkey. I think this
has a good list of the sort of things developers won't understand when
they arrive at the Mozilla code base:

- what to work on
- what's happening in the code base (what are others working on)
- typical workflows
- where to find documentation
- how to get a patch actually finished!

The documentation is a particular problem: MDC is unfriendly and
bitrotten (in this area), and tries to be all things to all people,
meaning that beginners find it hard to know what info is for them and
what isn't.

I don't believe we have any resources allocated to this. The fact that
we don't have dashboards tracking this sort of thing seems to mean it
isn't a high priority for us. AFAIK, we don't have tools and trackers
and people who go out and say "hi, how are you, is everything OK, can
I help you get this patch in?".

It might be a good idea for those interested in fixing this to meet
during the all hands to figure something out.

Paul


--
Paul Biggar
Compiler Geek
pbi...@mozilla.com

Dustin J. Mitchell

unread,
Mar 22, 2011, 5:48:06 PM3/22/11
to Joshua Cranmer, dev-pl...@lists.mozilla.org
On 3/22/11 3:51 PM, Joshua Cranmer wrote:
> what hope does a complete neophyte contributor have?

I have never attempted to build any of the Mozilla apps, much less
contribute, so I can't share a war-story, but I can say that this is a
*critical* part of Mozilla's continued existence as something more than
a software company that gives away its products for free.

We joke about the "Mozilla Firehose" and the endless complexity of all
things Mozilla, but we can do so because we're familiar with them and
know how to navigate them. For someone faced with a wall of
contradictory documentation, multiple source code repositories, half a
million bugzilla bugs, dozens of IRC channels, dozens of newsgroups, a
"custom" build process, and a tortuous patch-submission process designed
to suit full-time devs, it can be impenetrable -- even for someone who
is highly motivated and willing to spend months getting through the
process the first time.

As an organization, we spend a lot of time thinking about users'
experiences, and have built a number of incredible tools to measure and
facilitate those experiences. But it seems that we assume, as
developers, that we know what it's like to be a developer new to the
project. I think this assumption is entirely invalid.

It would be good to have some metrics - both quantitative and
qualitative - about new-developer experiences with Mozilla apps. Maybe
that means some case studies, along with tracking metrics for number of
new contributors and where they drop out of the pipeline? What kinds of
itches do new developers want to scratch, and how many of those are
practical? How many want to implement features that would never be
accepted?

Kudos to Joshua and Paul for their experimentation - a great start!

I know that there are good reasons for all of the roadblocks to new
contributors, and that they can't all be removed. I'm just not
convinced that measuring and reducing (or stabilizing) such roadblocks
is on the priority list.

If they are, then the task is easy: convince me :)

Dustin

Christian Legnitto

unread,
Mar 22, 2011, 6:45:04 PM3/22/11
to Dustin J. Mitchell, Joshua Cranmer, dev-pl...@lists.mozilla.org

On Mar 22, 2011, at 2:48 PM, Dustin J. Mitchell wrote:

> On 3/22/11 3:51 PM, Joshua Cranmer wrote:

>> what hope does a complete neophyte contributor have?
>

I'd like to pimp my bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=616089 - Create a new contributor linux development VM appliance that is constantly kept up to date

Thanks,
Christian

cka...@floodgap.com

unread,
Mar 22, 2011, 7:37:09 PM3/22/11
to
I'll just report my particular experiences as an outside utilizer of
Mozilla source. I maintain both TenFourFox and Classilla for old Macs,
which are legacy Mozilla-based browsers for PowerPC and OS 9,
respectively, and a couple of Firefox extensions, some personal and
some with an open userbase. So, while I'm not probably the heaviest
technical user outside MoFo/MoCo, I think I have representative
experience since I do have a userbase and I do build full-sized spin-
off applications.

I stick with Mozilla because I trust Mozilla source to be (mostly?)
free of outside bias, it has demonstrated cross-platform
compatibility, and is a standards-bearer. However, while I've written
my own code and submitted it a number of times (bugs 572000 and 624164
come to mind, off the top of my head), the only patch I've ever
submitted I know for sure got in the tree was a small trivial one to
fix a compile error with the mjit that Steve Fink committed on my
behalf. The rest of them are still sitting in review hell. That's,
bluntly, discouraging and Steve's post above summarizes the issues
pretty much as I would.

There are obviously people in the Mozilla team that are committed to
getting outside patches in. I would like to personally thank Boris for
his help on a couple of my bugs in the past, for example. However,
most of these I believe get downranked because they are uninteresting
to the majority or represent concerns valid only to a niche
population. If I may be so bold, that's sort of the point. If there's
an issue that's significant and has heavy-duty ramifications to the
majority of the Mozilla community, MoFo is going to put people and
money on it already. For the rest of us with an "itch to scratch," the
review system, while no doubt helping to keep the core stable, is also
a huge barrier to entry. Documentation is its own issue, but that's a
solvable problem. Reviews are hard because it's arbitrary and r+ may
entirely depend on whom you ask.

Much is made and said of "no free lunch," and I obviously understand
the rationale of the policy. However, for niche features, even if we
want to step up and work on them, no one is interested in taking them
(bug 572000). The usual counterargument to this is the cost of
supporting a niche feature. Well, frankly, if Mozilla wants to
encourage outside developers, that's a cost that you'll have to accept
to a certain level because outside core developers, niche is what
you're going to get (the low-hanging marquee features already have
devs on them). If the watchword is "we only want features we think
matter," then you're going to get a correspondingly smaller pool.

Take bug 621175, for example. The patches for 10.4 aren't wanted, and
I can understand why, even if I don't like that either. But even for
NPOTB patches, even working with a small group such as Adobe to get
the PPC nanojit in, it drags on and on. Fortunately I know exactly
where my r is eventually coming from (Rick) and an sr is probably
easier given it is NPOTB. But that's just luck and it was only because
Edwin Smith helped me out that I know where to go.

Now that I maintain my own browser forks, my checkin process is easy
because I accept the patches I want to accept in my own little
fiefdoms. I donate back the work I think is of community interest
where and when I have the time, but (and I hate to say this) whether
it gets in the tree or not is no longer something I particularly care
about, because odds are it probably won't. I believe in open source,
and I believe in giving back, which is why I still do it as time
permits. I would like to contribute more, but it's a discouraging
process when the likelihood of it actually reaching a point of benefit
is small.

My two cents.

Cameron Kaiser

Robert O'Callahan

unread,
Mar 22, 2011, 11:50:44 PM3/22/11
to Joshua Cranmer, dev-pl...@lists.mozilla.org
AFAIK the instructions here work:
https://developer.mozilla.org/En/Simple_Firefox_build
Perhaps we need to do something to make it easier to find. It's link #2
Googling "mozilla build windows". Probably what we most need at this point
is to remove the obsolete documentation.

Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Robert O'Callahan

unread,
Mar 23, 2011, 12:07:56 AM3/23/11
to Dustin J. Mitchell, Joshua Cranmer, dev-pl...@lists.mozilla.org
I think we're over-exaggerating a bit here :-).

On Wed, Mar 23, 2011 at 10:48 AM, Dustin J. Mitchell <dus...@mozilla.com>wrote:

> For someone faced with a wall of
> contradictory documentation,


Some obsolete stuff should be updated or removed, definitely.


> multiple source code repositories,


You only need http://hg.mozilla.org/mozilla-central to build Firefox.

half a million bugzilla bugs,


The total number of Bugzilla bugs is not really relevant to a new
contributor.

dozens of IRC channels


The IRC channels are a feature. If someone finds #developers they are very
likely to get all the help they need on that channel. If they're asking dev
questions on the wrong channel, someone should be redirecting them. I do not
see lost developers on IRC.

dozens of newsgroups


We should reduce them, but a new contributor does not need to know about
them.


> a "custom" build process


It's autoconf and make. It's really not very custom.


> and a tortuous patch-submission process designed
> to suit full-time devs


I'm not sure that it's particularly suited to full-time developers. The
process hasn't really changed since "super-review" first appeared in
2000-ish, which includes a period when there were hardly any full-time devs.

For a new contributor, one hard part of submitting a patch is knowing to
request review, and knowing who to request it from. Perhaps someone could do
a daily sweep of bugs with patches requesting review from nobody? The other
hard part of submitting a patch is when reviewers don't do timely reviews.
This is simply a matter of reviewers being conscientious. Perhaps another
periodic crack of the whip is in order. One workaround for both of those
problems is simply to contact certain people for help. Boris or I would do,
or #developers. That should be documented somewhere.

It would be good to have some metrics - both quantitative and
> qualitative - about new-developer experiences with Mozilla apps. Maybe
> that means some case studies, along with tracking metrics for number of
> new contributors and where they drop out of the pipeline? What kinds of
> itches do new developers want to scratch, and how many of those are
> practical? How many want to implement features that would never be
> accepted?
>

Updating MDC --- especially, removing or fixing obsolete information --- is
probably the most productive thing anyone can do right now. And fortunately,
anyone can do it!

Dustin J. Mitchell

unread,
Mar 23, 2011, 12:27:02 AM3/23/11
to rob...@ocallahan.org, Joshua Cranmer, dev-pl...@lists.mozilla.org
On 3/22/11 11:07 PM, Robert O'Callahan wrote:
> I think we're over-exaggerating a bit here :-).

Indeed. None of your responses are incorrect, but I suspect my post
captured the newcomer's perspective. Unknowns are big and scary!

> For a new contributor, one hard part of submitting a patch is knowing to
> request review, and knowing who to request it from.

Without meaning to pick on you specifically, what evidence do you have
for that assertion? (Well, I suppose "one hard part" is easily defended
- but do you know whether this is one of the five hardest parts? How?
What are the other top four hard parts?)

> Updating MDC --- especially, removing or fixing obsolete information ---
> is probably the most productive thing anyone can do right now. And
> fortunately, anyone can do it!

I don't disagree with you, but arguing "it's not that bad" is, IMHO, a
risky strategy when anecdotal evidence points to a very steep learning
curve (and a high mortality rate) for new contributors.

So, in short, I think that the new developer's perspective is missing in
the development-planning conversations since December, and that to avoid
our own biases we should be applying formal techniques to learn about
that perspective -- just like we do for novice *users* of our apps.

Dustin

Robert O'Callahan

unread,
Mar 23, 2011, 1:23:05 AM3/23/11
to Dustin J. Mitchell, Joshua Cranmer, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 5:27 PM, Dustin J. Mitchell <dus...@mozilla.com>wrote:

> > For a new contributor, one hard part of submitting a patch is knowing to
> > request review, and knowing who to request it from.
>
> Without meaning to pick on you specifically, what evidence do you have
> for that assertion?
>

Observing many examples of people requesting "r? from the wind" in bugs, or
attaching a patch and failing to request review.

Although the cases I see are usually quickly corrected by someone watching
the bug (usually not me). So maybe it isn't a huge problem overall. Depends
on how many bugs get patches but are not watched by anyone who knows the
system.

So, in short, I think that the new developer's perspective is missing in
> the development-planning conversations since December,


Those conversations have almost entirely been about how to get reviewed
patches landed, which is mostly orthogonal to the issues you raised. Boris,
myself and others have expressed the necessity for making it easy for
miscellaneous contributor patches to land in a timely manner.

and that to avoid
> our own biases we should be applying formal techniques to learn about
> that perspective -- just like we do for novice *users* of our apps.
>

Maybe, although developers are less important than users. It would be a
really interesting project though; not only would it help Mozilla, it would
shed light on open source software development in general. Dave Humphrey
probably has something to say about this.

Still, if you want to make a positive contribution, please edit MDC :-).

Robert O'Callahan

unread,
Mar 23, 2011, 1:25:32 AM3/23/11
to Dustin J. Mitchell, Joshua Cranmer, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 6:23 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:

> Still, if you want to make a positive contribution, please edit MDC :-).


Er, that sounded rude. Sorry.

I meant to say that editing the obsolete pages in MDC that appear high in
Google results is still the most positive contribution anyone can make right
now. IMHO.

David Humphrey

unread,
Mar 23, 2011, 10:28:12 AM3/23/11
to dev-pl...@lists.mozilla.org
I've been enjoying this thread. I think the fact that this discussion
is happening is good for the community, if only so that it reminds us
all that these things are important.

My experience has been that Mozilla's complexity is only ever dealt with
through relationships vs. resources. You can't write your way out of
this problem, since there is already too much written. Instead, I think
it's important to actively look for ways to help new people personally
via irc, bugs, etc.

Some of our developers are amazing at this. People like bz, shaver,
ted, jorendorff, gavin, joe, the list goes on, and I won't attempt to
name them all for fear of missing people. Watch them on irc, and in
bugs, and you'll see what I mean.

I really believe that more of us should be proactive in bugs to advocate
for people, defend them against unnecessary attacks or pedantic crap,
buffer them through irc channels, and above all encourage them. Most of
us can take getting banged around, when we are secure in our position
within the community; it's not the same for someone new.

There are enough of us who care about this that if we each do a bit to
help guide people through the maze, it isn't that much work. I've
brought hundreds of students into Mozilla, many of whom weren't your
typical Mozilla dev, and most survive and thrive. Mozilla is huge,
complicated, and hard, but with friends and mentors around, it is
manageable, even for beginners.

Dave

Gervase Markham

unread,
Mar 23, 2011, 10:43:26 AM3/23/11
to David Humphrey
On 23/03/11 14:28, David Humphrey wrote:
> My experience has been that Mozilla's complexity is only ever dealt with
> through relationships vs. resources. You can't write your way out of
> this problem, since there is already too much written.

I think we can unwrite ourselves out of it, to an extent. That is to
say, removing obsolete documentation.

> Instead, I think
> it's important to actively look for ways to help new people personally
> via irc, bugs, etc.

I think this is true, but it does have a certain amount of difficulty
scaling. We should try and reserve the time of the people you name below:

> Some of our developers are amazing at this. People like bz, shaver, ted,
> jorendorff, gavin, joe, the list goes on, and I won't attempt to name
> them all for fear of missing people.

...for filling in the gaps which can't be filled by documentation (e.g.
doing reviews and super-reviews).

> I really believe that more of us should be proactive in bugs to advocate
> for people, defend them against unnecessary attacks or pedantic crap,
> buffer them through irc channels, and above all encourage them.

Quick plug: if anyone sees someone handing out the attacks in Bugzilla,
contact me or another b.m.o. admin and we will take action.

Gerv

Gervase Markham

unread,
Mar 23, 2011, 10:47:15 AM3/23/11
to
On 22/03/11 16:29, Boris Zbarsky wrote:
> Please add:
>
> - Patches from people who are not paid to work on this thing.

I entirely agree that the fact that a patch was written by a volunteer
should be considered a point in favour of prioritizing it, in the same
way that it being a performance win would, or it being in high demand
from the webdev community. That is an awesome idea.

There is a risk that the new development system will lead to everyone
being even more stressed and busy all the time than they are now,
because we will always be close to a release. How can we make sure
existing core community members are able to invest time in tomorrow's
core community members?

I think that a '20% time' thing for Mozilla employees would be awesome -
every Mozilla employee must spend one day a week looking for,
encouraging, reviewing the patches of, discussing things with or
generally involving people who are not employed.

(Some people, of course, will be above 20% already.)

Gerv

Joshua Cranmer

unread,
Mar 23, 2011, 10:47:32 AM3/23/11
to
On 03/23/2011 12:07 AM, Robert O'Callahan wrote:
>
>> a "custom" build process
> It's autoconf and make. It's really not very custom.
>
Last time I checked, I couldn't ./configure && make, or autoconf-2.13 &&
./configure && make. It's not exactly a standard build system, then;
given that we don't seem to particularly care about realigning the build
system with standard convention, we probably need at least a README file
in the distribution that tells neophyte developers that this isn't the
conventional setup.

Axel Hecht

unread,
Mar 23, 2011, 11:40:41 AM3/23/11
to
On 22.03.11 21:27, Dustin J. Mitchell wrote:
> On 3/22/11 11:07 PM, Robert O'Callahan wrote:
>> I think we're over-exaggerating a bit here :-).
>
> Indeed. None of your responses are incorrect, but I suspect my post
> captured the newcomer's perspective. Unknowns are big and scary!
>
>> For a new contributor, one hard part of submitting a patch is knowing to
>> request review, and knowing who to request it from.
>
> Without meaning to pick on you specifically, what evidence do you have
> for that assertion? (Well, I suppose "one hard part" is easily defended
> - but do you know whether this is one of the five hardest parts? How?
> What are the other top four hard parts?)
>

I have tons of practical experience with this in l10n land.

The sentence "attach your patch and request review" is full of jargon,
basically. It implies all of:

make a patch (diff, review the diff yourself, diff to file, kdiff for
you instead? oh, nifty)
create an attachment in bugzilla, mark it as patch
find the 'review' flag, and map "request review" to setting the drop
down next to it to "?"
entering a bugzilla ID as requestee (which is already a word that
non-native speakers probably have issues with wrt English skills)

I see people fail often on this, in particular in l10n land, and I
assume that newcomers are on a similar level when it comes down to FLOSS
and bugzilla jargon.

Axel

Janet Swisher

unread,
Mar 23, 2011, 12:08:43 PM3/23/11
to rob...@ocallahan.org, Joshua Cranmer, dev-pl...@lists.mozilla.org, Dustin J. Mitchell

On 3/23/11 12:25 AM, Robert O'Callahan wrote:
> On Wed, Mar 23, 2011 at 6:23 PM, Robert O'Callahan<rob...@ocallahan.org>wrote:
>
>> Still, if you want to make a positive contribution, please edit MDC :-).
>
> Er, that sounded rude. Sorry.
>
> I meant to say that editing the obsolete pages in MDC that appear high in
> Google results is still the most positive contribution anyone can make right
> now. IMHO.
>

More specifically, ways that you can help improve MDC:

* If you find a page that is outdated, and you know what info to update
it with, please do so.
* If you find a page that is outdated, and you don't know how to update
it, or don't have time, tag it with "NeedsTechnicalReview", and add a
comment to the corresponding Talk page describing what is needed.
* If you find a page that is too out of date to salvage, tag it with
"Obsolete" (with a Talk page comment if possible). This lets the wiki
admins know that it should be archived, or at least flagged with a big
fat "Obsolete" banner.

--Janet


Paul Biggar

unread,
Mar 23, 2011, 2:49:52 PM3/23/11
to Janet Swisher, Dustin J. Mitchell, Joshua Cranmer, rob...@ocallahan.org, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 9:08 AM, Janet Swisher <jswi...@mozilla.com> wrote:
>>On Wed, Mar 23, 2011 at 6:23 PM, Robert O'Callahan<rob...@ocallahan.org>wrote:
>>> Still, if you want to make a positive contribution, please edit MDC :-).
> More specifically, ways that you can help improve MDC:
>
> * If you find a page that is outdated, and you know what info to update it
> with, please do so.
> * If you find a page that is outdated, and you don't know how to update it,
> or don't have time, tag it with "NeedsTechnicalReview", and add a comment to
> the corresponding Talk page describing what is needed.
> * If you find a page that is too out of date to salvage, tag it with
> "Obsolete" (with a Talk page comment if possible). This lets the wiki admins
> know that it should be archived, or at least flagged with a big fat
> "Obsolete" banner.

I have come across pages where it is very difficult to know what to
do, and where I am not able to answer these questions:

- Is this page obsolete?
- What should happen with the sorta-old info on it?
- Is the advanced information on this page useful or in the way?
- Is the organization of this set of pages
- Should I add information which already exists elsewhere (but perhaps
in a different form)?
- If I fix the page organization for some subgroup (lets say
beginners), do I ruin it for some other group (perhaps non-beginners).

I've had this same problem at least three times, and each time
retreated in confusion.

To be honest, I don't think we're dealing with this in the right way.
We wouldn't ask people with a casual understanding of the code base to
commit "fixes", or have numerous developers working on the same code
without communicating, and without a shared vision for the end result.
I think we lack a set of principles by which to update MDC, for
example:

- how should information be arranged so that it can benefit both
beginners and advanced users?
- how can we gauge the "right way" to add information to a page?
- is there an owner we can contact for guidance?
- how do we communicate with others who are interested in the same information?

Ian Gilman

unread,
Mar 23, 2011, 4:42:21 PM3/23/11
to
For what it's worth, most of the devs on the Panorama team were new to
Mozilla development, so we created this wiki page:

https://wiki.mozilla.org/Firefox/Projects/TabCandy/Work

... that got them quickly up to speed on the project and how to work
in the Mozilla system. Though not perfect, it certainly helped.

Nicholas Nethercote

unread,
Mar 23, 2011, 5:01:59 PM3/23/11
to Joshua Cranmer, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 1:47 AM, Joshua Cranmer <Pidg...@verizon.net> wrote:
> On 03/23/2011 12:07 AM, Robert O'Callahan wrote:
>>
>>> a "custom" build process
>>
>> It's autoconf and make. It's really not very custom.
>>
> Last time I checked, I couldn't ./configure && make, or autoconf-2.13 &&
> ./configure && make. It's not exactly a standard build system, then

Yes. I found the required use of a mozconfig to be an obstacle, esp.
since no two people seem to have the same mozconfig. And then you
can't just do "make" but have to do "make -f client.mk build" or
similar. (Maybe you can do something different and/or better now, but
that's the magic incantation I embedded in my wrapper script two years
ago after some trial and error.)

Nick

Robert O'Callahan

unread,
Mar 23, 2011, 5:20:54 PM3/23/11
to Nicholas Nethercote, Joshua Cranmer, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 10:01 AM, Nicholas Nethercote <
n.neth...@gmail.com> wrote:

> Yes. I found the required use of a mozconfig to be an obstacle, esp.
> since no two people seem to have the same mozconfig. And then you
> can't just do "make" but have to do "make -f client.mk build" or
> similar. (Maybe you can do something different and/or better now, but
> that's the magic incantation I embedded in my wrapper script two years
> ago after some trial and error.)
>

I assume you hadn't found
https://developer.mozilla.org/En/Simple_Firefox_build?

If so, that confirms we just need to unwrite ourselves some documentation to
make sure that page is the first hit for the appropriate searches :-).

Janet Swisher

unread,
Mar 23, 2011, 6:25:15 PM3/23/11
to Paul Biggar, Eric Shepherd, Dustin J. Mitchell, Joshua Cranmer, rob...@ocallahan.org, dev-pl...@lists.mozilla.org

I agree that more communication about these issues would be good.

The mailing list for MDC is https://lists.mozilla.org/listinfo/dev-mdc

How about starting a thread there about how to structure information for
new Mozilla developers?

IRC discussions for MDC take place in #devmo. During US business hours,
Sheppy and I are usually there. We have contributors in Europe and
Australia who are fairly knowledgeable about the site and may be online
at other hours. However, they may decline to give strategic/IA advice.
(BTW, we have a community meeting for MDC contributors in #devmo at
10:00am PT on alternate Wednesdays; the next one is on March 30.)

In the bigger picture, I think it would be awesome to apply some of
Mozilla's user experience brainpower to the total experience of new
contributors (not just docs, but the whole process of getting involved).
I believe David Boswell and the Contributor Engagement team are working
on some aspects of this, but the groups that interact with contributors
(dev, QA, l10n, etc.) are the experts on their own processes.

--Janet

Robert Kaiser

unread,
Mar 23, 2011, 6:56:02 PM3/23/11
to
Gervase Markham schrieb:

> I think that a '20% time' thing for Mozilla employees would be awesome -
> every Mozilla employee must spend one day a week looking for,
> encouraging, reviewing the patches of, discussing things with or
> generally involving people who are not employed.

Interesting idea!

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)

Asa Dotzler

unread,
Mar 23, 2011, 7:07:33 PM3/23/11
to
On 3/22/2011 11:29 AM, Steve Fink wrote:

> That's my long-winded way of agreeing with bz. External contributors
> should have a greased path into the repository,

I'm not picking on you (praise be to you and others in this thread
trying to make things better,) but you're an easy hook for this request.

Can we please stop referring to people not paid by Mozilla as
"external"? Mozilla (the company) is a contributor to the Mozilla
project. Yes, it's a huge contributor but it is still a contributor, and
the not-paid-by-Mozilla contributors are just as internal to the project
as are those who are paid by Mozilla. There is no internal and external
here.

The same goes for the phrase "the community". Mozilla (the company) is a
part of the Mozilla community. It's a big part, but it is not a separate
thing from the community.

If you're looking for a good word to describe a person or group of
people not paid by Mozilla, please try some of these on for size:

volunteers, volunteer contributors, community volunteers, Mozilla
volunteers, etc.

Thanks,

- A


Nicholas Nethercote

unread,
Mar 23, 2011, 7:26:35 PM3/23/11
to rob...@ocallahan.org, Joshua Cranmer, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 2:20 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> I assume you hadn't found
> https://developer.mozilla.org/En/Simple_Firefox_build?

I can't remember the exact steps I went through, but I did see and
follow this page. The mozconfig and non-standard make invocation was
still strange; I was expecting a simpler configure+make experience.
Also, it doesn't take long before that simple mozconfig isn't enough
-- it doesn't enable tests, it doesn't allow for 32-bit builds on
64-bit machines, etc, etc. No real developer has a mozconfig that
simple, right?

Nick

Ted Mielczarek

unread,
Mar 23, 2011, 7:56:48 PM3/23/11
to Nicholas Nethercote, dev-pl...@lists.mozilla.org

Not to nit-pick you, but we have been striving over the past few years
to make the default configuration as close to what we ship as
possible. The default configuration does enable tests, builds an
optimized build, and just about everything else that we can do without
special requirements. I've been thinking about making
--enable-application default to "browser" as well, so that "configure
&& make" would work out-of-the-box.

-Ted

Mike Shaver

unread,
Mar 23, 2011, 8:11:16 PM3/23/11
to Nicholas Nethercote, Joshua Cranmer, rob...@ocallahan.org, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 4:26 PM, Nicholas Nethercote

<n.neth...@gmail.com> wrote:
> On Wed, Mar 23, 2011 at 2:20 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>>
>> I assume you hadn't found
>> https://developer.mozilla.org/En/Simple_Firefox_build?
>
> I can't remember the exact steps I went through, but I did see and
> follow this page.  The mozconfig and non-standard make invocation was
> still strange;  I was expecting a simpler configure+make experience.
> Also, it doesn't take long before that simple mozconfig isn't enough
> -- it doesn't enable tests, it doesn't allow for 32-bit builds on
> 64-bit machines, etc, etc.  No real developer has a mozconfig that
> simple, right?

On Mac my mozconfig contains exactly --enable-application=browser --
it builds tests and everything else. Sometimes I have
"--enable-profiling --enable-optimize" there for specific tasks.
Often I don't even bother with a mozconfig and just run configure by
hand. We should probably make --enable-application default to
browser, since that's by far the dominant use, but if we gave the
"need enable-application" error message right away rather than after 2
mins of configure that might suffice.

On Windows I disable angle and a11y because I don't have the SDKs.
Following the full build instructions obviates that, though. (I also
use pymake on Windows, but that's an optimization due to gmake's awful
performance under msys.)

Cross-compiling is advanced magic on every project I've worked on that
had any meaningful system-specific code, or tools built in the
process. Don't get me started on crossing glibc or the kernel. It's
hard on the Mac IIRC because Apple doesn't provide gcc-$target for the
32-bit stuff, so you have to dork around with all the various CFLAGS.

Most of the complexity in the build instructions are due to:

- still having text about building old branches, which I think we
should immediately move to "old stuff" pages (I'm volunteering)
- needing autoconf-2.13 because of the incompatibility; I forget what
we use that modern autoconf doesn't provide, but it was non-trivial
- having all the instructions about which SDKs to download, how to get
stuff from Macports, etc. We should streamline these too.

The instructions are a little more compleatist than is probably
helpful. They're a little "well, actually..." and not really focused
on what new developers want: the shortest path to a firefox binary
they can start up. But the build system itself doesn't have to be
very complex at all.

Mike

davidwboswell

unread,
Mar 23, 2011, 8:33:09 PM3/23/11
to
> I believe David Boswell and the Contributor Engagement team are working
> on some aspects of this, but the groups that interact with contributors
> (dev, QA, l10n, etc.) are the experts on their own processes.

On the mozilla.org/contribute pages we've been experimenting with ways
to help people interested in getting involved with Mozilla become
active contributors.

One thing we've done is to invite people to contact us if they have
questions about how to contribute. This means we regularly get emails
like this:

"I want to help work on firefox but I have never contributed to OSS
before. The whole project is a little daunting though, I could use a
little help getting started (little bug fixes, documentation, whatever
you need)."

About 100 people have been contacting us through that page each week.
Based on best practices from other non-profits, if we're performing
well then 1 out of 10 of those people should be expected to become
active volunteers.

We don't have great metrics here yet so we don't know how successful
we've been, but it doesn't feel like we've added 10 new active
contributors to the project each week over the last year and a half.

I'd be very happy to work with people here to do a number of things
mentioned in this thread:

* Create easy to understand getting started information and good
initial project ideas to send to people who ask questions like the one
above.

* Create a group of mentors to help and encourage people who are
expressing interest in contributing.

* Create a better way to determine what is working and what isn't
working in the process of bringing in new active contributors.

Looking forward to talking more in this thread and in person. The new
#mozillians channel on IRC is also a good place to discuss ideas about
how to help new people become active contributors.

David

Robert Kaiser

unread,
Mar 23, 2011, 8:35:49 PM3/23/11
to
Joshua Cranmer schrieb:
> Perversely, the only reason I knew how to get my patch committed was
> because I had to bear enough handholding that I became familiar with the
> process by the time it got to that point.

Well, not so sure that's "perversely". Any such large code-base probably
needs some hand-holding until you get how to deal with it (try the Linux
kernel or Wine and you'll probably also need some time to get started).

The reason why the SeaMonkey project is - for its rather small volume in
users - reasonably effective in getting contributors that help with code
(even though review can sometimes be a hard step in that project) is
that people spend a lot of time on IRC and do a lot of hand-holding to
get people acquainted, to make them feel good in the project.

I experienced a lot of that in the L10n community when I came into the
Mozilla project, which encouraged me to get more and more involved, and
I always tried to communicate a lot with people who are interested in
seeing something changed, esp. if they seem to be willing to take action
theirselves.

IMHO, we should find some way to encourage Mozilla employees do that
without making us be less productive overall (I'd think that serving as
a multiplier, it should actually make us more productive), and I think
Gerv's "20% time" idea posted earlier in this group could be one
possibility to try and improve this.

We surely should try and improve documentation and think about how we
could make the whole process of contribution easier, but from my POV,
the most important part is that we need to actively communicate with
interested people and do some hand-holding on their first steps into the
community.

When (I think we can, so it's a "when", not an "if") we manage that, we
already achieve a lot.

Robert Kaiser

unread,
Mar 23, 2011, 8:58:36 PM3/23/11
to
davidwboswell schrieb:

> One thing we've done is to invite people to contact us if they have
> questions about how to contribute.

I think it's great we give them this possibility. What we need to try
hard to do is to reply back to them and give them some pointers (which
we need to have available, of course) to the specific areas they are
asking about, or at least who to connect with on that area.
And yes, there needs to be personal contact, not just docs. People want
to feel they are part of the community when they are contributing, so
personal contact is very important. We're a community of humans, not of
web servers (well, probably a bit of both *g*).

Mike Shaver

unread,
Mar 23, 2011, 9:01:10 PM3/23/11
to davidwboswell, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 5:33 PM, davidwboswell <davidw...@yahoo.com> wrote:
> "I want to help work on firefox but I have never contributed to OSS
> before. The whole project is a little daunting though, I could use a
> little help getting started (little bug fixes, documentation, whatever
> you need)."

What, specifically, is the response to this?

Mike

Mike Shaver

unread,
Mar 23, 2011, 9:07:37 PM3/23/11
to Asa Dotzler, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 4:07 PM, Asa Dotzler <a...@mozilla.com> wrote:
> If you're looking for a good word to describe a person or group of people
> not paid by Mozilla, please try some of these on for size:

I think the relevant partition in this discussion is "external"
meaning "not from someone already close to the project": people who
don't know who to ask for help, how to navigate bugzilla, etc. F.e.,
I would consider philor to be "internal", and from a
getting-a-patch-done perspective I would count many of our
non-developer employees. (Such employees have lamented the
difficulty, in fact!)

Mike

Stormy Peters

unread,
Mar 23, 2011, 9:24:34 PM3/23/11
to Mike Shaver, davidwboswell, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 7:01 PM, Mike Shaver <mike....@gmail.com> wrote:

> On Wed, Mar 23, 2011 at 5:33 PM, davidwboswell <davidw...@yahoo.com>
> wrote:

> > "I want to help work on firefox but I have never contributed to OSS
> > before. The whole project is a little daunting though, I could use a
> > little help getting started (little bug fixes, documentation, whatever
> > you need)."
>

> What, specifically, is the response to this?
>

GNOME has a GNOME Love project[1]. In addition to a mailing list and IRC
channel, bugs that are easy for beginners to tackle are marked as GNOME Love
bugs.

I know several professors that ask their students to find and solve GNOME
Love bugs as a way to get started.

Another idea would be to hold a time at conferences where people could bring
their laptops and get help setting up their build environments.

Stormy

[1] https://live.gnome.org/GnomeLove

Boris Zbarsky

unread,
Mar 23, 2011, 9:25:51 PM3/23/11
to
On 3/23/11 8:33 PM, davidwboswell wrote:
> One thing we've done is to invite people to contact us if they have
> questions about how to contribute. This means we regularly get emails
> like this:
>
> "I want to help work on firefox but I have never contributed to OSS
> before. The whole project is a little daunting though, I could use a
> little help getting started (little bug fixes, documentation, whatever
> you need)."

What do you say to them?

> * Create easy to understand getting started information and good
> initial project ideas to send to people who ask questions like the one
> above.

For code work we have some of this (good first bug annotations and the
simple build instructions). For other things, I'm not sure...


> * Create a group of mentors to help and encourage people who are
> expressing interest in contributing.

I think it shouldn't be hard to find volunteers here. Count me in.

-Boris

Mike Shaver

unread,
Mar 23, 2011, 9:26:57 PM3/23/11
to sto...@mozilla.com, davidwboswell, dev-pl...@lists.mozilla.org, Stormy Peters
On Wed, Mar 23, 2011 at 6:24 PM, Stormy Peters <spe...@mozilla.com> wrote:
> GNOME has a GNOME Love project[1]. In addition to a mailing list and IRC
> channel, bugs that are easy for beginners to tackle are marked as GNOME Love
> bugs.

Both the gnome-love and gnome-women projects are ones that I would
love to see us emulate. I don't know if that falls into dboswell's
current scope or if it needs more thrust.

Mike

Asa Dotzler

unread,
Mar 23, 2011, 9:27:02 PM3/23/11
to

OK. I misread some of this thread and was thinking it was about people
already in the system but working on things that Mozilla leadership
doesn't put high value on and so were at risk of having their patches
rot and that that might get worse in a shorter release cycle with
stricter rules.

- A

Mike Shaver

unread,
Mar 23, 2011, 9:59:48 PM3/23/11
to Asa Dotzler, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 6:27 PM, Asa Dotzler <a...@mozilla.com> wrote:
> OK. I misread some of this thread and was thinking it was about people
> already in the system but working on things that Mozilla leadership doesn't
> put high value on and so were at risk of having their patches rot and that
> that might get worse in a shorter release cycle with stricter rules.

People that can't get their stuff it are by definition on the outside,
I think, and we should strive to bring them in. Employees will be
working on things that don't make the cut, but I don't think the rot
risk goes up, since it's proportionate to change rate, and that
shouldn't be affected much by the new system.

Mike

Joshua Cranmer

unread,
Mar 23, 2011, 10:14:10 PM3/23/11
to
On 03/23/2011 08:11 PM, Mike Shaver wrote:
> - needing autoconf-2.13 because of the incompatibility; I forget what
> we use that modern autoconf doesn't provide, but it was non-trivial
How hard would it be to get the auto-update configure back in? That kind
of mitigates the need for autoconf-2.13...

davidwboswell

unread,
Mar 23, 2011, 11:01:30 PM3/23/11
to
> > "I want to help work on firefox but I have never contributed to OSS
> > before. The whole project is a little daunting though, I could use a
> > little help getting started (little bug fixes, documentation, whatever
> > you need)."
>
> What do you say to them?

For this inquiry, I sent this person the following response:

https://wiki.mozilla.org/Mozilla.org/Contribute/Canned_responses#Coding

I maintain a wiki page of responses to common inquiries and then edit
that as needed if people ask specific questions about a given topic.

One thing that would be helpful to get from this thread is an improved
response to people interested in getting involved in coding (or any
other project areas people have useful getting started information
for). Feel free to edit the wiki or send me suggestions.

Getting the response right is important, but I also think the act of
responding and making a connection is far more important than the
content of the response. Even if we had perfect documentation that
people could find or be sent, we'd still want a way to let people get
their foot in the door in terms of meeting other Mozillians.

> > * Create a group of mentors to help and encourage people who are
> > expressing interest in contributing.
>
> I think it shouldn't be hard to find volunteers here.  Count me in.

That's great. Thanks for that.

Right now the system we have for bringing in inquiries and handling
responses is a hack. I quickly put a 0.1 version of this contributor
input process together to see what would happen and we'll work to
improve that this year.

I'd be happy to walk you, or anyone else, through the current kludgy
system or I can get back to you when a more useful system is in place.

David

Mook

unread,
Mar 24, 2011, 1:17:28 AM3/24/11
to
On 3/23/2011 4:07 PM, Asa Dotzler wrote:
> On 3/22/2011 11:29 AM, Steve Fink wrote:
>
>> That's my long-winded way of agreeing with bz. External contributors
>> should have a greased path into the repository,
>
> I'm not picking on you (praise be to you and others in this thread
> trying to make things better,) but you're an easy hook for this request.
>
> Can we please stop referring to people not paid by Mozilla as
> "external"? Mozilla (the company) is a contributor to the Mozilla
> project. Yes, it's a huge contributor but it is still a contributor, and
> the not-paid-by-Mozilla contributors are just as internal to the project
> as are those who are paid by Mozilla. There is no internal and external
> here.
>

I would consider myself very much in this "external" group.

I have (or rather, had [1]) commit access. Nonetheless, trying to do
anything useful is harder than pulling teeth, because 1) I'm never
working on Firefox directly, meaning 2) module peers/reviewers are
always either working on whatever new feature (pre-beta) or the next
blocker (beta+) instead of my patch, and 3) it typically doesn't make
sense for me to work during ZST workweek (because I have an actual job
to do), so asking anything in IRC when I do have time - at times roughly
approaching midnight - usually leads to dead silence. Checking in
doesn't work either, since that's something like 6 hours when I tried (a
long time back, actually), and due to the above time zone problems, no
real way to figure out which particular known orange something is.
Essentially, posting patches feels more like throwing it over a wall,
since I can't expect a response in any useful time frame. I don't
_want_ this to be the case, but there really isn't much I can do about
it. (In terms of the no free lunch analogy: the lunch lady refuses to
take my money, something about my money not being company-issued.)

At least I managed to get past the "building something" stage back in
the cygwin days... I'm probably not your typical case, though; going by
MozillaZine posts, I started building eight years ago.

I've been following the whole release + new plan thing for a while now;
just have been keeping silent because, while having this discussion
about bring in more contributors is nice, I feel nothing will change
until the people in charge -- drivers, (MoCo) management (since they
drive Firefox and the resource behind it), shaver/gerv/mitchell in their
"the buck stops here" capacities -- decide they want it, this will just
go exactly where the previous calls for participation go. My goals are
about making Mozilla awesome, not about making Firefox awesome, even
though there's large amounts of overlap.

If there's a public declaration of sinking more resources into getting
external (there's that word again!) patches in, and a little bit more
highlight on successful instances of it happening, I'd be quite happy to
sink more time in. At this point, however, I mainly just post patches
of things I have because I like to share, not because I have any hopes
of committing.

[1] L3; my account got disabled because I hadn't checked in anything -
because I found the requirement to run the full test suite locally
prohibitive (a clean build fails tests the last time I tried). There
was no notification.

--
Mook

L. David Baron

unread,
Mar 24, 2011, 1:39:36 AM3/24/11
to Mook, dev-pl...@lists.mozilla.org
On Wednesday 2011-03-23 22:17 -0700, Mook wrote:
> [1] L3; my account got disabled because I hadn't checked in anything
> - because I found the requirement to run the full test suite locally
> prohibitive (a clean build fails tests the last time I tried).

There's no such requirement. If something says there is, we should
fix it.

That said, you should run the tests that you feel are appropriate,
and use https://wiki.mozilla.org/Build:TryServer as appropriate for
additional testing on the real infrastructure. If your definition
of "as appropriate" turns out to be off, we expect you to learn from
your mistakes. If you don't, people will tell you to be more
careful. (In theory, in extreme cases, we could revoke somebody's
access for breaking the tree too often, but I don't think we've ever
done that.)

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Mike Hommey

unread,
Mar 24, 2011, 5:28:34 AM3/24/11
to Nicholas Nethercote, Joshua Cranmer, rob...@ocallahan.org, dev-pl...@lists.mozilla.org
On Wed, Mar 23, 2011 at 04:26:35PM -0700, Nicholas Nethercote wrote:
> On Wed, Mar 23, 2011 at 2:20 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> >
> > I assume you hadn't found
> > https://developer.mozilla.org/En/Simple_Firefox_build?
>
> I can't remember the exact steps I went through, but I did see and
> follow this page. The mozconfig and non-standard make invocation was
> still strange; I was expecting a simpler configure+make experience.

FWIW, except for --enable-application=browser, you can very much have a
"normal" configure + make experience, provided you use the source
tarballs. With the source coming from mercurial, you only need to first
run autoconf2.13 in the main directory as well as in js/src, and then
you're back to "normal" configure + make.

client.mk is only a facility. And when you have a lot of ac_add_options,
it's just simpler to use client.mk + mozconfig than to build a configure
command each time. But newcomers don't need to know that.

Actually, I think the Simple Firefox build page should just say

- ./configure --enable-application=browser (and remove
--enable-application=browser when we make it the default)
- make
- profit

Then point to the more subtle variant:

- mkdir objdir
- cd objdir
- ../configure --enable-application=browser
- make
- profit

And only then talk about mozconfig and client.mk, possibly even on a
separate page.

Mike

Kyle Huey

unread,
Mar 24, 2011, 7:14:22 AM3/24/11
to davidwboswell, dev-pl...@lists.mozilla.org
It would be interesting to know what our "conversion rate" is here. In
other words, how many of the folks that show up asking for a way to help
code ever end up getting a patch into the tree? I'd be really impressed if
it is greater than 1%.

I think the best thing we can do with these inquiries is to refer them
one-on-one to people that have been around a while and can point them in the
right direction and answer questions.

- Kyle

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

Gervase Markham

unread,
Mar 24, 2011, 8:23:11 AM3/24/11
to Asa Dotzler
On 23/03/11 23:07, Asa Dotzler wrote:
> The same goes for the phrase "the community". Mozilla (the company) is a
> part of the Mozilla community. It's a big part, but it is not a separate
> thing from the community.
>
> If you're looking for a good word to describe a person or group of
> people not paid by Mozilla, please try some of these on for size:
>
> volunteers, volunteer contributors, community volunteers, Mozilla
> volunteers, etc.

The trouble with "volunteers" or related words is that it makes a
distinction between those who are paid and those who are not, and I
don't think that's a good distinction to major on.

Also, there are people paid to work on Mozilla (i.e. not volunteers) who
are not paid by Mozilla. Bob Relyea at Red Hat is one such.

I actually prefer the "community" language, but I agree it's not perfect
either, for the reasons you give.

(I think this is an important discussion, not a bikeshedding point.)

Gerv

Gervase Markham

unread,
Mar 24, 2011, 8:24:22 AM3/24/11
to Mook
On 24/03/11 05:17, Mook wrote:
> [1] L3; my account got disabled because I hadn't checked in anything -
> because I found the requirement to run the full test suite locally
> prohibitive (a clean build fails tests the last time I tried). There was
> no notification.

What David said, and also: getting your account re-enabled should be as
easy as filing an IT bug and waiting a few hours - or less, if you ping
them on IRC. If it's harder than that, tell me.

Gerv

Gervase Markham

unread,
Mar 24, 2011, 8:24:29 AM3/24/11
to
On 24/03/11 05:17, Mook wrote:
> [1] L3; my account got disabled because I hadn't checked in anything -
> because I found the requirement to run the full test suite locally
> prohibitive (a clean build fails tests the last time I tried). There was
> no notification.

What David said, and also: getting your account re-enabled should be as

Jeff Hammel

unread,
Mar 24, 2011, 1:29:51 PM3/24/11
to dev-pl...@lists.mozilla.org
New contributors are also much better at knowing their pain points than,
well, people that are familiar. When we're lucky enough to get new
contributors -- whether they are interns, new hires, or otherwise
interested in the Mozilla community -- it would be nice to pay attention
and document things that are barriers to entry. I've only been here a
year, and already I've forgotten about my initial pain points.

Just a thought...

Ehsan Akhgari

unread,
Mar 24, 2011, 2:57:56 PM3/24/11
to Mike Hommey, Joshua Cranmer, Nicholas Nethercote, rob...@ocallahan.org, dev-pl...@lists.mozilla.org

This is all great and all, but I think a simple INSTALL file in the root
directory explaining this stuff goes a long way. That's basically how I
build all of the software that I download from the source.

Cheers,
Ehsan

Steve Fink

unread,
Mar 24, 2011, 3:39:17 PM3/24/11
to dev-pl...@lists.mozilla.org
On 03/23/2011 10:17 PM, Mook wrote:
> I have (or rather, had [1]) commit access. Nonetheless, trying to do
> anything useful is harder than pulling teeth, because 1) I'm never
> working on Firefox directly, meaning 2) module peers/reviewers are
> always either working on whatever new feature (pre-beta) or the next
> blocker (beta+) instead of my patch, and 3) it typically doesn't make
> sense for me to work during ZST workweek (because I have an actual job
> to do), so asking anything in IRC when I do have time - at times
> roughly approaching midnight - usually leads to dead silence.
> Checking in doesn't work either, since that's something like 6 hours
> when I tried (a long time back, actually), and due to the above time
> zone problems, no real way to figure out which particular known orange
> something is.

Just addressing the orange point:

Have you found the automated orange starring suggestions on tbpl useful?
Or haven't you found them? I find tbpl somewhat new-user-hostile, so
just in case, go to a try server push on
http://tbpl.mozilla.org/?tree=MozillaTry and look for oranges. Click on
the orange letter. It handles a good percentage of known oranges well.
If "Retrieving summary..." times out, as it often will, try again
immediately.

As a broader note, our orange epidemic is a serious impediment for new
committers.

On running the test suite locally:

Others have brought up the try server. I'd also like to mention that it
can be very helpful to download the try-built binary and tests for your
platform and run the individual failing tests locally, especially when
you're building with different compile flags that avoid the problem and
hence make your own build useless. There's always a way to select
individual tests or a subset of tests, though digging up what it is has
historically been a major pain. It's gotten better, so I'm not going to
claim that everything is still broken, but I would guess that it's still
harder than it ought to be. I've put a small amount of work into that,
but haven't had much impact yet.

Neither tbpl nor arbpl <http://arbpl.visophyte.org/> make it easy to get
to the build directories yet, but if it's your own push you'll have it
in email or you can navigate through from
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/

Steve Fink

unread,
Mar 24, 2011, 3:52:03 PM3/24/11
to dev-pl...@lists.mozilla.org
On 03/23/2011 04:07 PM, Asa Dotzler wrote:
> On 3/22/2011 11:29 AM, Steve Fink wrote:
>
>> That's my long-winded way of agreeing with bz. External contributors
>> should have a greased path into the repository,
>
> I'm not picking on you (praise be to you and others in this thread
> trying to make things better,) but you're an easy hook for this request.
>
> Can we please stop referring to people not paid by Mozilla as
> "external"? Mozilla (the company) is a contributor to the Mozilla
> project. Yes, it's a huge contributor but it is still a contributor,
> and the not-paid-by-Mozilla contributors are just as internal to the
> project as are those who are paid by Mozilla. There is no internal and
> external here.
>
> The same goes for the phrase "the community". Mozilla (the company) is
> a part of the Mozilla community. It's a big part, but it is not a
> separate thing from the community.
>
> If you're looking for a good word to describe a person or group of
> people not paid by Mozilla, please try some of these on for size:
>
> volunteers, volunteer contributors, community volunteers, Mozilla
> volunteers, etc.

Ok. Then assuming we'll give special priority to new-submitter patches,
"greased volunteers" it is!

Thinking about the difficulty in terminology is a good way to come up
with some useful metrics for this stuff:

Measure patch submissions, reviews and review lags, landings and landing
lags along the axes of
- age of bugzilla account
- number of patches submitted by this submitter
- whether a submitter is employed by Mozilla Corp
- whether a submitter is paid to work on Mozilla
- age of submitter's first-ever patch
- timezone of submitter
- native language of submitter
- age of submitter
- number of bugzilla comments written by submitter
- whether a submitter has commit privs
- fuzzy heuristic combinations of the above to bucket people into "new
unpaid volunteer" or whatever

I'm not saying that all or any of those are easy to collect, just that
they all seem potentially enlightening. Perhaps not immediately from a
snapshot, but the trends over time at least could be useful metrics for
judging how well we're doing.

Then we could go crazy and correlate build breakages, perf and bloat
hits, add-on breakages, etc. with the same metrics, and evaluate
the cost (technical debt?) incurred by each category of contributors...

I'll go back in my corner now.

Boris Zbarsky

unread,
Mar 24, 2011, 5:08:19 PM3/24/11
to
On 3/23/11 11:01 PM, davidwboswell wrote:
> For this inquiry, I sent this person the following response:
>
> https://wiki.mozilla.org/Mozilla.org/Contribute/Canned_responses#Coding

OK. I think explicitly pointing them at the lists of good first bugs
and student projects might also be a good idea...

If you agree, I'll add that to the wiki.

-Boris

Wes Garland

unread,
Mar 24, 2011, 5:27:01 PM3/24/11
to Steve Fink, dev-pl...@lists.mozilla.org
You know, the biggest problem I've had as a (very very small-time)
contributor is a straight-up management problem:

If I have an idea, or a conundrum (i.e. I can fix this one of three ways) --
there isn't really a way to vet it other than
- implementing it and requesting code-review
- nagging the module owner or a peer on IRC until you finally get his
attention and then see if you can pin him down one way or the other
- filing a bug, CCing the module owner or a peer and waiting to see if
anything happens

I've tried all three approaches over the years. The first one seems to be
the most effective, but also by far the most expensive for me. And it can
still take months to get feedback. I hate the second one. By the time the
third one's rolled around, I've often worked around whatever itch I wanted
to scratch, so nothing ever happens.

In the corporate-in-house-developer world, I would normally be able to run
an idea past a manager in a quick three-minute chat, yielding a bit of
direction, which would at least let me smartly invest the time to implement,
then post a patch in bugzilla hoping for a review.

Another management problem, as well, is -- what happens to r+ code that
isn't checked in? I don't have this problem personally, but I've seen other
occasional contributors stymied after the r+. I have also pushed patches
for other developers, but I don't really feel comfortable doing that when
they are for features I can't test personally -- basically, I don't want a
rep as a guy who lights up the tree unless it's with my own code.

Anyhow. Food for thought! sfink suggested an "r?-for-comments" idea on
IRC. I think something like that might work if the moz culture embraced
it.

Wes

PS: This message might sound like angry whining, but it isn't. If we
weren't already talking about "what makes it hard for outsiders to
contribute", I wouldn't have said boo. I'm just trying to relay experiences
to improve the community.

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

Blake Kaplan

unread,
Mar 24, 2011, 5:55:32 PM3/24/11
to
Wes Garland <w...@page.ca> wrote:
> Anyhow. Food for thought! sfink suggested an "r?-for-comments" idea on
> IRC. I think something like that might work if the moz culture embraced
> it.

AIUI, that was what "feedback?" was supposed to be: "this patch isn't ready to
get checked in, but what do you think of this approach/general idea."
--
Blake Kaplan

Nicholas Nethercote

unread,
Mar 24, 2011, 6:15:55 PM3/24/11
to Steve Fink, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 12:39 PM, Steve Fink <sf...@mozilla.com> wrote:
>
> Have you found the automated orange starring suggestions on tbpl useful?

I'd like to say that as a non-newbie I find these suggestions
extraordinarily helpful. They make random oranges vastly easier to
deal with. (I try to star my oranges ASAP but philor usually beats me
to it :) Kudos to the kind souls who implemented it and to those who
file and maintain the bugs.

Nick

Robert O'Callahan

unread,
Mar 24, 2011, 6:24:06 PM3/24/11
to Kyle Huey, davidwboswell, dev-pl...@lists.mozilla.org
Quite frequently I get contacted by email by people who want to contribute
to development. I used to send them replies pointing to our documentation
and offering to answer any questions and give any other help they might
need. I almost never got any reply and none of those people ever turned into
useful contributors. So after a few years of that I stopped replying.

Of course we have had, and still have, great new contributors, and many of
them do ask for help along the way. They just haven't started by asking for
help, at least not by asking me.

Rob

Dan Mosedale

unread,
Mar 24, 2011, 6:32:50 PM3/24/11
to Mike Shaver, Boris Zbarsky, dev-pl...@lists.mozilla.org
On 3/22/11 9:49 AM, Mike Shaver wrote:
> On Tue, Mar 22, 2011 at 9:41 AM, Boris Zbarsky<bzba...@mit.edu> wrote:
>> I'm saying that we should consider as part of the "value" of a patch whether
>> it helps us grow our set of contributors.
> I think that's a good idea. I might go so far as to make it someone's
> job on a rotating basis, like sheriffing (but over a longer period).
This is an intriguing idea, but it's not obvious to me what exactly the
"it" refers to in that sentence. Can you unpack a bit?

Dan

Wes Garland

unread,
Mar 24, 2011, 6:33:08 PM3/24/11
to Blake Kaplan, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 5:55 PM, Blake Kaplan <mrb...@gmail.com> wrote:

> AIUI, that was what "feedback?" was supposed to be: "this patch isn't ready
> to
> get checked in, but what do you think of this approach/general idea."
>

We're still missing a step if I understand the flags correctly: f? is
"what do you think of this, it's mostly working", r? is "Okay, this works,
is it up to snuff?"

What we're missing, I think, is a "Hey, what do you think of this
approach?" -- where the approach is described in 50-200 words of prose.

Would most owners/peers know what to do with a text file full of prose with
an f? flag? If yes -- then maybe this should be pointed out somewhere? I
can't remember ever seeing anything regarding planning outside of bug
comments.

Wes

Dan Mosedale

unread,
Mar 24, 2011, 6:32:29 PM3/24/11
to David Humphrey, dev-pl...@lists.mozilla.org
On 3/23/11 7:28 AM, David Humphrey wrote:
> My experience has been that Mozilla's complexity is only ever dealt
> with through relationships vs. resources. You can't write your way
> out of this problem, since there is already too much written. Instead,
> I think it's important to actively look for ways to help new people
> personally via irc, bugs, etc.

It strikes me that this is really a battle that can be fought on
multiple fronts.

At a macro level, I think you're absolutely right, that we need to tweak
our social systems to be more welcoming (I love the mentoring discussion
elsewhere in this thread!) And we already have some mailing lists with
explicit policies against flaming, ranting, etc. There's quite a bit
more we can, I expect.

However, there are also things that just need saner defaults (eg without
a .mozconfig), having the build do anything other than build firefox
seems weird. And there are also things that we can automate and monitor
our ways out of, as mentioned by other folks on this thread.

Dan

Dan Mosedale

unread,
Mar 24, 2011, 6:33:48 PM3/24/11
to Janet Swisher, Eric Shepherd, dev-pl...@lists.mozilla.org, rob...@ocallahan.org, Dustin J. Mitchell, Paul Biggar, Joshua Cranmer
On 3/23/11 3:25 PM, Janet Swisher wrote:
> In the bigger picture, I think it would be awesome to apply some of
> Mozilla's user experience brainpower to the total experience of new
> contributors (not just docs, but the whole process of getting involved).
Completely agree that devoting significant UX brainpower here could make
a big difference. In a sense, the Mozilla project is itself a product
that contributors need to use and engage with. This implies (and I
strongly believe) that interaction design effort (including metrics,
user-testing, and monitoring) can significantly help us here.

Dan

Blake Kaplan

unread,
Mar 24, 2011, 6:47:35 PM3/24/11
to
Wes Garland <w...@page.ca> wrote:
> We're still missing a step if I understand the flags correctly: f? is
> "what do you think of this, it's mostly working", r? is "Okay, this works,
> is it up to snuff?"

Ah, yeah. FWIW, I don't think that "mostly working" is necessarily a
prerequisite to asking for f?, but I see your point.

> What we're missing, I think, is a "Hey, what do you think of this
> approach?" -- where the approach is described in 50-200 words of prose.

It sounds to me like this should be solved by filing a new bug (or adding a
comment to an existing bug) and letting the module owner leave it or
WONTFIX/INVALIDate it. I guess the problem is that we have enough new bugs and
module owners generally don't have the bandwidth to keep up, so the idea never
receives any feedback?

> Would most owners/peers know what to do with a text file full of prose with
> an f? flag? If yes -- then maybe this should be pointed out somewhere? I
> can't remember ever seeing anything regarding planning outside of bug
> comments.

Well, we *are* talking about people here. If someone asks me for feedback on
something and I see a bunch of prose, I hope I'd be able to figure out the
right response :-). That being said, I don't know of anybody doing this right
now.
--
Blake Kaplan

Robert O'Callahan

unread,
Mar 24, 2011, 6:57:59 PM3/24/11
to Blake Kaplan, dev-pl...@lists.mozilla.org

I don't really like feedback? since it feels like "I have to review this now
and then later I'll have to review it again". I would rather people just
tell me by email or in a bug what they want to do. However, I do try to
respond to all feedback? and review? in a timely manner, in most cases, and
I think all other developers should as well.

Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Dan Mosedale

unread,
Mar 24, 2011, 7:48:48 PM3/24/11
to Steve Fink, dev-pl...@lists.mozilla.org
*chuckle* about greased volunteers.

I completely agree that metrics are key to helping us both discover
where we need to improve and actually make those improvements, and am
involved with a few other folks in producing some.

A while back, I wrote up a
<https://wiki.mozilla.org/User:Dmose:Simple_Metrics>
with some thinking about the low-hanging fruit around contribution
metrics. As a result of that, I hacked up a version of the "hg
activity" extension to produce some metrics as described in
<http://redpuma.net/blog/?p=690>, which links to a spreadsheet with that
data from comm-central.

Several of us met in December and decided we'd like to experiment with
putting it in a more usable and useful form (a dashboard version), and
we hope to have something to ready to show there before too long...

Dan

Stormy Peters

unread,
Mar 24, 2011, 7:54:23 PM3/24/11
to Dan Mosedale, Joshua Cranmer, Eric Shepherd, dev-pl...@lists.mozilla.org, Dustin J. Mitchell, Paul Biggar, rob...@ocallahan.org
Another place to test ideas and get feedback is with professors. Professors
that use open source software in their classrooms look for projects that are
easy to install and get started with.

Stormy

Dan Mosedale

unread,
Mar 24, 2011, 7:55:30 PM3/24/11
to Jeff Hammel, dev-pl...@lists.mozilla.org
A fine idea, I think.

One thing that one sometimes sees on the web is a "Feedback" tab on the
side of page, typically leading to GetSatisfaction. It occurs to me
that we could actually have two tabs (assuming sufficient help lay
beyond them):

Feedback for when somebody just has feedback on the page itself

and

Stuck? Which could try to put them in email (or even chat!) contact
with a mentor...

Dan

Boris Zbarsky

unread,
Mar 24, 2011, 8:35:11 PM3/24/11
to
On 3/24/11 5:27 PM, Wes Garland wrote:
> - nagging the module owner or a peer on IRC until you finally get his
> attention and then see if you can pin him down one way or the other

Replace irc with email (possibly to our developer lists), and this is
probably the best approach. At least in my experience.

> - filing a bug, CCing the module owner or a peer and waiting to see if
> anything happens

This, combined with email pointing out the bug, can also work pretty well.

> In the corporate-in-house-developer world, I would normally be able to run
> an idea past a manager in a quick three-minute chat, yielding a bit of
> direction, which would at least let me smartly invest the time to implement,
> then post a patch in bugzilla hoping for a review.

Right. You just want the equivalent of that chat; the problem is that
chances are the guy you want to have it with is asleep when you want to
have it, so it needs to be asynchronous... ;)

I understand that there's the concern about bothering "busy people" by
mailing them. The thing to keep in mind is that being module owner
means that you are responsible for giving exactly the sort of feedback
we're talking about here. That's what module owners are supposed to do.

> Another management problem, as well, is -- what happens to r+ code that
> isn't checked in?

It rots. We should be avoiding this situation, whenever possible. And
yes, it does happen (including patches by people who have push access).
Just like people who probably know better sometimes attach a patch and
forget to ask for review.

When in doubt, mail the bug owner in question and ask them whether they
want you to push the patch for them.

> I don't have this problem personally, but I've seen other
> occasional contributors stymied after the r+.

If you see this happening, please feel free to let me know. It will be
dealt with.

> I have also pushed patches for other developers, but I don't really feel comfortable doing that when
> they are for features I can't test personally -- basically, I don't want a
> rep as a guy who lights up the tree unless it's with my own code.

While I understand the sentiment, sometimes we need to make sacrifices.
;) And try server does make it easier to have peace of mind here...

> Anyhow. Food for thought! sfink suggested an "r?-for-comments" idea on
> IRC. I think something like that might work if the moz culture embraced
> it.

Sure. The main benefit over email to a developer list would be that the
stuff would be segregated by bug, right? And the benefit over private
mail is that it would be archived (though private threads can be pasted
into a bug as needed too).

-Boris

Wes Garland

unread,
Mar 24, 2011, 8:41:59 PM3/24/11
to Dan Mosedale, Steve Fink, dev-pl...@lists.mozilla.org
> As a result of that, I hacked up a version of the "hg activity" extension
to produce some
> metrics as described in <http://redpuma.net/blog/?p=690>,

Of course, the most infrequent contributors -- the ones with the biggest
potential, I believe -- are also the most succeptible to mis-reporting in
hg. I understand perfectly that the plural of anecdote is not data, but --
of the very, very small number of patches I've had committed
- 21% don't have my name in the user: field
- 10% don't have my e-mail address in the user: field nor comments
- 5% don't mention me in the commit log at all

I'm all for collecting information, but my gut suggests that the users we
want to target the most are also going to have the least reliable data. So:
can we improve the data over the long term?

Would it make sense to create a tool (shell script) which can
1) Download a patch from bugzilla given the URL
2) Apply it to the current repo
3) Let the human sort out the conflicts etc
4) Check in the patch using information from bugzilla
5) Maybe sanity-check hg out
6) Maybe generate the hg push command line

If yes, how could we get it worked into the Moz work flow? Is there a group
within moz that works on tools like this?

Kyle Huey

unread,
Mar 24, 2011, 8:48:13 PM3/24/11
to Wes Garland, Steve Fink, dev-pl...@lists.mozilla.org, Dan Mosedale
We call this tool qimportbz and it can be found at
http://hg.mozilla.org/users/robarnold_cmu.edu/qimportbz/

Also, anyone committing patches on behalf of others should be ensuring that
the author information is correct ...

- Kyle

Wes Garland

unread,
Mar 24, 2011, 8:53:52 PM3/24/11
to Kyle Huey, Steve Fink, dev-pl...@lists.mozilla.org, Dan Mosedale
On Thu, Mar 24, 2011 at 8:48 PM, Kyle Huey <m...@kylehuey.com> wrote:

> We call this tool qimportbz and it can be found at
> http://hg.mozilla.org/users/robarnold_cmu.edu/qimportbz/
>

Wow! That was easy! I'll be sure to give it a whirl the next time I have
something to push.

How do we communicate to people with commit access that this tool exists and
is highly recommended?

Boris Zbarsky

unread,
Mar 24, 2011, 8:55:08 PM3/24/11
to
On 3/24/11 8:41 PM, Wes Garland wrote:
> Of course, the most infrequent contributors -- the ones with the biggest
> potential, I believe -- are also the most succeptible to mis-reporting in
> hg. I understand perfectly that the plural of anecdote is not data, but --
> of the very, very small number of patches I've had committed
> - 21% don't have my name in the user: field

This makes sense as something that can happen to someone's first patch.
After that, someone should have linked you to our sample hgrc that
solves this problem.... the only issue is that I can't find it. :( I
swear we had it.

In any case, you want this:

[defaults]
qnew = -U

[ui]
username = First Last <email@somewhere>

and then make sure that the patches you attach either come from your mq
or are generated by export or bzexport. That way you get to pick your
checkin comment too.

I agree with your larger point that the existing data is hopelessly
polluted, by the way, but let's at least solve your attribution problem. ;)

> 1) Download a patch from bugzilla given the URL
> 2) Apply it to the current repo
> 3) Let the human sort out the conflicts etc
> 4) Check in the patch using information from bugzilla

http://hg.mozilla.org/users/robarnold_cmu.edu/qimportbz or so, right?

Maybe we need better docs on it; googling "qimportbz" doesn't find much
in the way of recent stuff. This does help for cases when the patch in
the bug doesn't have the right metadata; for cases when it does just |hg
qimport https://bugzilla-url| works just dandy.

> 5) Maybe sanity-check hg out
> 6) Maybe generate the hg push command line

There's nothing to generate. The command line is |hg push|. ;)

-Boris

L. David Baron

unread,
Mar 24, 2011, 9:12:57 PM3/24/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Thursday 2011-03-24 20:55 -0400, Boris Zbarsky wrote:
> On 3/24/11 8:41 PM, Wes Garland wrote:
> >Of course, the most infrequent contributors -- the ones with the biggest
> >potential, I believe -- are also the most succeptible to mis-reporting in
> >hg. I understand perfectly that the plural of anecdote is not data, but --
> >of the very, very small number of patches I've had committed
> > - 21% don't have my name in the user: field
>
> This makes sense as something that can happen to someone's first
> patch. After that, someone should have linked you to our sample
> hgrc that solves this problem.... the only issue is that I can't
> find it. :( I swear we had it.

It's in https://developer.mozilla.org/en/Installing_Mercurial ,
although half of it is in the "Configuration" section and then
another half of it is in the "Configuring mq" section.

Maybe we should just assume people want mq and merge them? Though I
occasionally hear some people don't.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Wes Garland

unread,
Mar 24, 2011, 10:59:20 PM3/24/11
to Blake Kaplan, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 6:47 PM, Blake Kaplan <mrb...@gmail.com> wrote:

> That being said, I don't know of anybody doing this right
> now.
>

I think I'll try this the next time or two this comes up. It's cheap to try,
and be a productivity win! :)

Wes Garland

unread,
Mar 24, 2011, 11:25:17 PM3/24/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 8:55 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 3/24/11 8:41 PM, Wes Garland wrote:
>
>> Of course, the most infrequent contributors -- the ones with the biggest
>> potential, I believe -- are also the most succeptible to mis-reporting in
>> hg. I understand perfectly that the plural of anecdote is not data, but
>> --
>> of the very, very small number of patches I've had committed
>> - 21% don't have my name in the user: field
>>
>
> This makes sense as something that can happen to someone's first patch.
> After that, someone should have linked you to our sample hgrc that solves
> this problem.... the only issue is that I can't find it. :( I swear we had
> it.
>

I just re-reviewed https://developer.mozilla.org/en/Mercurial_FAQ for the
first time in a couple of years. The documentation is even better, but it
barely mentions mq. To be clear, I've always been of the impression that mq
would offer someone who only works one thing at a time (like me) little gain
but increased complexity (basically that it would give me "Quilt" on top of
hg). I never had a clue that mq was the gateway to generating patches with
additional meta data; I've been using 'hg diff'.


> Maybe we need better docs on it; googling "qimportbz" doesn't find much in
> the way of recent stuff.


I think the biggest hurdle is knowing that it exists! You know -- there
must be a list somewhere of people with commit access. Is that a mailing
list? Are things like qimportbz announced on it?


> There's nothing to generate. The command line is |hg push|. ;)
>

In my case, I use | hg push ssh://hg.mozilla.org/tracemonkey/ -e 'ssh -l
w...@page.ca' | -- I guess this is probably because I normally work with the
http:// repo.

But at the time I wrote that, I was thinking about making sure that we
didn't accidentally push a new head, or patches we didn't mean to. Upon
further reflection, the first is unnecessary (it warns IIRC) and the second
isn't really practical.

Something to think about -- the first time I checked something in, I made a
point of reviewing all documentation I could find to that effect. Then I
checked it in on the try server, then pushed to tracemonkey. This wasn't all
that long ago, and I'm "around" enough to absorb a bit of moz-practice by
osmosis. If I'm doing things inefficiently, it's a good bet that plenty of
others are, too.

Boris Zbarsky

unread,
Mar 25, 2011, 12:11:35 AM3/25/11
to
On 3/24/11 11:25 PM, Wes Garland wrote:
> I never had a clue that mq was the gateway to generating patches with
> additional meta data; I've been using 'hg diff'.

Well, you could also hg commit and hg export and get metadata. But yes,
if you just hg diff, then there's no metadata available in the result...

But yes, we don't really make this clear.

Note that a patch with good metadata is _way_ easier to push for someone
else, by the way. :)

> Is that a mailing list?

Not one I know anything about.

> In my case, I use | hg push ssh://hg.mozilla.org/tracemonkey/ -e 'ssh -l
> w...@page.ca' | -- I guess this is probably because I normally work with the
> http:// repo.

[paths]
default-push = ssh://w...@page.ca@hg.mozilla.org/tracemonkey/

In either that tree's hgrc or your ~/.hgrc should help with that problem.


> But at the time I wrote that, I was thinking about making sure that we
> didn't accidentally push a new head, or patches we didn't mean to. Upon
> further reflection, the first is unnecessary (it warns IIRC) and the second
> isn't really practical.

Yep.

> Something to think about -- the first time I checked something in, I made a
> point of reviewing all documentation I could find to that effect. Then I
> checked it in on the try server, then pushed to tracemonkey. This wasn't all
> that long ago, and I'm "around" enough to absorb a bit of moz-practice by
> osmosis. If I'm doing things inefficiently, it's a good bet that plenty of
> others are, too.

I'm pretty darn sure they are, yes (including myself)!

-Boris

Mook

unread,
Mar 25, 2011, 1:22:15 AM3/25/11
to
On 3/24/2011 12:39 PM, Steve Fink wrote:
> Just addressing the orange point:
>
> Have you found the automated orange starring suggestions on tbpl useful?
> Or haven't you found them? I find tbpl somewhat new-user-hostile, so
> just in case, go to a try server push on
> http://tbpl.mozilla.org/?tree=MozillaTry and look for oranges. Click on
> the orange letter. It handles a good percentage of known oranges well.
> If "Retrieving summary..." times out, as it often will, try again
> immediately.

Yes, I know about tbpl. At least four instances of it, actually
(mozilla.org, ehsan, dbaron, mstange) with no clear direction on which
one is not broken in some way. I find it not so useful, because it's
mostly client-side, which means it slows down my browser into
unusability [1]. The few times I've tried it, the suggestions were not
useful - perhaps it's gotten better?

> As a broader note, our orange epidemic is a serious impediment for new
> committers.

And while it's gotten _slightly_ better, it's still rather horrible. (I
would consider it not horrible when philor doesn't have to do anything
anymore.)

Aside: I also have no confidence that the practice of starring oranges
is actually _useful_ - it's just generating useless noise (in bugs and
in tinderboxen), but judging by the bug with ~200 of them, not
conductive to fixing things.

> On running the test suite locally:

> Others have brought up the try server. I'd also like to mention that it
> can be very helpful to download the try-built binary and tests for your
> platform and run the individual failing tests locally, especially when
> you're building with different compile flags that avoid the problem and
> hence make your own build useless. There's always a way to select
> individual tests or a subset of tests, though digging up what it is has
> historically been a major pain. It's gotten better, so I'm not going to
> claim that everything is still broken, but I would guess that it's still
> harder than it ought to be. I've put a small amount of work into that,
> but haven't had much impact yet.

Try server requires commit access (at least L1). That might be good
enough for me if I try to get my access reinstated, but it'll never be
good enough for new people (where the whole point is that they _don't_
already have commit access). If the solution to any of this discussion
involves try server, it's wrong.

Running the try-built binaries locally involves having the right OS.
That's not always the case, especially if you don't happen to have a
machine that has enough RAM to run spare VMs. When evaluating this:
please remember to not count any machine paid for by MoCo/MoFo.

Amusingly, while there may be ways to select individual tests or subsets
of tests, [2] doesn't say how to run _all_ of the tests (multiple
suites). Again, assume no try server access, and assume somebody not
familiar enough to know which tests are relevant.

In some ways, it's better than it used to be - at least there's a page I
can point at now! - and yet it's at the same time worse (since now we
actually know when things get broken).

> Neither tbpl nor arbpl <http://arbpl.visophyte.org/> make it easy to get
> to the build directories yet, but if it's your own push you'll have it
> in email or you can navigate through from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/

[1] All of Rouget's demos are measured in seconds per frame on my
machine as well. I suspect everybody over there is testing with
developer machines with fancy hardware - though I would have thought a
2.1G Turion X2 with a Radeon HD3200 would have been good enough.

[2] https://developer.mozilla.org/en/mozilla_automated_testing

--
Mook

Philip Chee

unread,
Mar 25, 2011, 1:28:52 AM3/25/11
to
On Thu, 24 Mar 2011 18:33:08 -0400, Wes Garland wrote:
> On Thu, Mar 24, 2011 at 5:55 PM, Blake Kaplan <mrb...@gmail.com> wrote:
>
>> AIUI, that was what "feedback?" was supposed to be: "this patch isn't ready
>> to
>> get checked in, but what do you think of this approach/general idea."
>>
>
> We're still missing a step if I understand the flags correctly: f? is
> "what do you think of this, it's mostly working", r? is "Okay, this works,
> is it up to snuff?"
>
> What we're missing, I think, is a "Hey, what do you think of this
> approach?" -- where the approach is described in 50-200 words of prose.
>
> Would most owners/peers know what to do with a text file full of prose with
> an f? flag? If yes -- then maybe this should be pointed out somewhere? I
> can't remember ever seeing anything regarding planning outside of bug
> comments.

I've seen this in comm-central. Someone putting up a proposal as a text
attachment with f? for discussion. Seems to work.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

Nicholas Nethercote

unread,
Mar 25, 2011, 1:34:33 AM3/25/11
to dev-pl...@lists.mozilla.org
On Fri, Mar 25, 2011 at 4:22 PM, Mook
<mook.moz+nntp.n...@gmail.com.please-avoid-direct-mail>
wrote:

>
> Aside: I also have no confidence that the practice of starring oranges is
> actually _useful_ - it's just generating useless noise (in bugs and in
> tinderboxen), but judging by the bug with ~200 of them, not conductive to
> fixing things.

As for whether adding the details to the bug is useful, I don't know.
But having the star on the TBPL display is crucial. I star oranges
(or philor beats me to it) as they come in. As I periodically check
back, I don't have to remember which oranges I've already decided were
pre-existing.

Nick

Message has been deleted

Steve Fink

unread,
Mar 25, 2011, 1:47:52 AM3/25/11
to dev-pl...@lists.mozilla.org, Phil Ringnalda
On 03/24/2011 10:22 PM, Mook wrote:
> On 3/24/2011 12:39 PM, Steve Fink wrote:
>> Just addressing the orange point:
>>
>> Have you found the automated orange starring suggestions on tbpl useful?
>> Or haven't you found them? I find tbpl somewhat new-user-hostile, so
>> just in case, go to a try server push on
>> http://tbpl.mozilla.org/?tree=MozillaTry and look for oranges. Click on
>> the orange letter. It handles a good percentage of known oranges well.
>> If "Retrieving summary..." times out, as it often will, try again
>> immediately.
>
> Yes, I know about tbpl. At least four instances of it, actually
> (mozilla.org, ehsan, dbaron, mstange) with no clear direction on which
> one is not broken in some way. I find it not so useful, because it's
> mostly client-side, which means it slows down my browser into
> unusability [1]. The few times I've tried it, the suggestions were
> not useful - perhaps it's gotten better?

...and then there's arbpl: http://arbpl.visophyte.org/

I think it fixes much of the client-heaviness, and has lots of other
improvements besides. But it's not relevant here, because it doesn't
have the starring suggestions yet.

At least now, tbpl's suggestions are very good, or so it seems to me.
But they still won't do you any good if you don't have access to push to
try. I'd forgotten about that little detail. :-(

>
> Aside: I also have no confidence that the practice of starring oranges
> is actually _useful_ - it's just generating useless noise (in bugs and
> in tinderboxen), but judging by the bug with ~200 of them, not
> conductive to fixing things.

Apparently philor did an experiment by taking a break at some point. I
wasn't around, but it sounded like it was a disaster. Real failures
piled up and people get pushing anyway. Or so that was the vague
impression I got. philor?

> Amusingly, while there may be ways to select individual tests or
> subsets of tests, [2] doesn't say how to run _all_ of the tests
> (multiple suites). Again, assume no try server access, and assume
> somebody not familiar enough to know which tests are relevant.

Again, I was assuming try server access, which is currently the only
reasonable way to run tests for most developers. They take too damn
long. You're right, of course, about the uselessness of try if you don't
have commit privs.

>
> [1] All of Rouget's demos are measured in seconds per frame on my
> machine as well. I suspect everybody over there is testing with
> developer machines with fancy hardware - though I would have thought a
> 2.1G Turion X2 with a Radeon HD3200 would have been good enough.

Are you getting hardware acceleration? (Check for a Graphics section in
about:support)

Steve Fink

unread,
Mar 25, 2011, 2:00:11 AM3/25/11
to dev-pl...@lists.mozilla.org, Ted Mielczarek

qimportbz needs a new owner or a replacement. I know this because I sent
Rob Arnold a patch for a pretty major bug with imported patch naming (I
think an hg update broke it), and he replied saying he's not working on
Mozilla stuff much anymore, so he isn't really maintaining it. I've
neglected to try pushing my fix to his repo as he said I could.

Ted, could qimportbz be integrated into or rewritten for your bzexport
stuff? If not, I guess I could fork the qimportbz repo and start
maintaining its current incarnation.

Asa Dotzler

unread,
Mar 25, 2011, 2:34:53 AM3/25/11
to
On 3/24/2011 10:22 PM, Mook wrote:

> [1] All of Rouget's demos are measured in seconds per frame on my
> machine as well. I suspect everybody over there is testing with
> developer machines with fancy hardware - though I would have thought a
> 2.1G Turion X2 with a Radeon HD3200 would have been good enough.

No, everyone over here isn't testing with fancy hardware. Lots of folks
have machines that are older, especially in QA (or laptops which are
always slower.) I run a core 2 duo at 1.4GHz with integrated intel
graphics and I've never experienced seconds per frame on any of Paul's
demos. I wonder why my dramatically inferior specs generate such
superior results.

- A

Robert O'Callahan

unread,
Mar 25, 2011, 4:11:22 AM3/25/11
to dev-pl...@lists.mozilla.org
On Fri, Mar 25, 2011 at 6:22 PM, Mook <mook.moz+nntp.news.mozilla.org
@gmail.com.please-avoid-direct-mail> wrote:

> Yes, I know about tbpl. At least four instances of it, actually (
> mozilla.org, ehsan, dbaron, mstange) with no clear direction on which one
> is not broken in some way. I find it not so useful, because it's mostly
> client-side, which means it slows down my browser into unusability [1]. The
> few times I've tried it, the suggestions were not useful - perhaps it's
> gotten better?


I find it fantastically useful, and everyone around me does too. It's a lot
faster now than it used to be too; if you haven't tried it for a while, try
it again.


> As a broader note, our orange epidemic is a serious impediment for new
>> committers.
>>
>
> And while it's gotten _slightly_ better, it's still rather horrible. (I
> would consider it not horrible when philor doesn't have to do anything
> anymore.)
>

Realistically, thanks to hg you can now be very deep into Mozilla work
without having commit access to mozilla-central. If you can get someone else
to commit your patches --- and if you hang out on #developers or know
someone with commit access, you probably can --- it's really more convenient
to NOT have commit access.

Commit access is no longer the essential part of being a contributor that it
used to be. Committing to mozilla-central is not something new contributors,
or even not-so-new contributors, need to deal with.

Aside: I also have no confidence that the practice of starring oranges is
> actually _useful_ - it's just generating useless noise (in bugs and in
> tinderboxen), but judging by the bug with ~200 of them, not conductive to
> fixing things.


It tells us which orange bugs are the most important to work on, and some of
those bugs get fixed, so it's definitely useful.

Try server requires commit access (at least L1). That might be good enough
> for me if I try to get my access reinstated, but it'll never be good enough
> for new people (where the whole point is that they _don't_ already have
> commit access). If the solution to any of this discussion involves try
> server, it's wrong.
>

The tryserver does help new contributors. If a new contributor produces a
risky patch, it's easy for someone else with commit access to push that
patch to the tryserver and then commit to mozilla-central if the results are
good.

[1] All of Rouget's demos are measured in seconds per frame on my machine as
> well. I suspect everybody over there is testing with developer machines
> with fancy hardware - though I would have thought a 2.1G Turion X2 with a
> Radeon HD3200 would have been good enough.
>

Actually many of us test on phones these days.

Maybe your machine is broken in some way. Anyway, the performance of Paul's
graphics-heavy demos is likely entirely unrelated to the performance of
tbpl.

Henri Sivonen

unread,
Mar 25, 2011, 4:44:19 AM3/25/11
to dev-pl...@lists.mozilla.org
On Thu, 2011-03-24 at 17:27 -0400, Wes Garland wrote:
> You know, the biggest problem I've had as a (very very small-time)
> contributor is a straight-up management problem:
>
> If I have an idea, or a conundrum (i.e. I can fix this one of three ways) --
> there isn't really a way to vet it other than
> - implementing it and requesting code-review

> - nagging the module owner or a peer on IRC until you finally get his
> attention and then see if you can pin him down one way or the other
> - filing a bug, CCing the module owner or a peer and waiting to see if
> anything happens

It doesn't make this any better, but people whose Gecko development
activity is paid for by Mozilla have this problem, too. (Well, at least
I have had it.)

I think there's definitely room for process improvement here. I think we
need some known way to get a reviewer on hook ahead of writing a patch
and getting the reviewer to agree before the patch is written to the
general approach that will be taken when writing the patch.

If attaching a plan written in English to Bugzilla and raising the
feedback flag on the attachment is the mechanism, I think it would be
worthwhile to communicate better that that's the mechanism, because I
hadn't realized that doing it that way was an option.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Robert O'Callahan

unread,
Mar 25, 2011, 5:29:05 AM3/25/11
to Henri Sivonen, dev-pl...@lists.mozilla.org
On Fri, Mar 25, 2011 at 9:44 PM, Henri Sivonen <hsiv...@iki.fi> wrote:

> It doesn't make this any better, but people whose Gecko development
> activity is paid for by Mozilla have this problem, too. (Well, at least
> I have had it.)
>

We all have it.


> I think there's definitely room for process improvement here. I think we
> need some known way to get a reviewer on hook ahead of writing a patch
> and getting the reviewer to agree before the patch is written to the
> general approach that will be taken when writing the patch.
>

We're all human beings here. People have been talking to each other and
making commitments to each other long before Bugzilla existed :-). Use
Bugzilla, use email, use IRC, use Skype (underrated as a collaboration tool
IMHO!), but just talk :-).

Kyle Huey

unread,
Mar 25, 2011, 6:21:52 AM3/25/11
to Wes Garland, Boris Zbarsky, dev-pl...@lists.mozilla.org
On Thu, Mar 24, 2011 at 11:25 PM, Wes Garland <w...@page.ca> wrote:

> On Thu, Mar 24, 2011 at 8:55 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>

> > Maybe we need better docs on it; googling "qimportbz" doesn't find much
> in
> > the way of recent stuff.
>
>

> I think the biggest hurdle is knowing that it exists! You know -- there
> must be a list somewhere of people with commit access. Is that a mailing
> list? Are things like qimportbz announced on it?
>
>

There's commi...@mozilla.org. I think the only mail I've ever gotten from
it was about updating the MPL (I've only been a committer since the
beginning of 2010). It's definitely not used for announcements like that.

- Kyle

Robert Kaiser

unread,
Mar 25, 2011, 11:28:42 AM3/25/11
to
Robert O'Callahan schrieb:

> On Fri, Mar 25, 2011 at 6:22 PM, Mook<mook.moz+nntp.news.mozilla.org
> [1] All of Rouget's demos are measured in seconds per frame on my machine as
>> well. I suspect everybody over there is testing with developer machines
>> with fancy hardware - though I would have thought a 2.1G Turion X2 with a
>> Radeon HD3200 would have been good enough.
>
> Actually many of us test on phones these days.

This is very much of a side-track the the discussion, but while not
officially a demo and instead something we heavily touted as an official
page in the last days, glow.mozilla.org has been slightly sluggish on my
Core2 Duo Laptop, maybe because we don't support any hw accel on an open
graphics stack (Linux + Intel drivers in this case) and completely
unusable (didn't even get a single download number) on my phone (N900).

Also, running all tests proved to be a "go for an hour of shopping or
more and try to see if the failures could be related to your system"
experience every time I tried - and I never saw a full test pass go
green on any of my machines. But perhaps once again Linux is at the
disadvantage there.

I also have learned to not be too eager to get small fixup or cleanup
patches into Firefox as all I really know how to deal with is XUL/CSS
and some JS, and anything touching UI does not only have a higher effort
in getting testing and comments on all tier-1 platforms, but is also
sensitive enough that it's harder to get it reviewed than any
backend-only stuff - or anything that some module owner or peer thinks
is "cool" and drives himself to inclusion.

That said, I mostly don't dare to check into mozilla-central any more
because of the orange watching topic already mentioned here and getting
angry comments about orange in completely unrelated tests when checking
in some tiny UI cleanup.

Robert Kaiser

--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)

Mike Hommey

unread,
Mar 25, 2011, 11:58:00 AM3/25/11
to Robert Kaiser, dev-pl...@lists.mozilla.org
On Fri, Mar 25, 2011 at 04:28:42PM +0100, Robert Kaiser wrote:
> Robert O'Callahan schrieb:
> >On Fri, Mar 25, 2011 at 6:22 PM, Mook<mook.moz+nntp.news.mozilla.org
> >[1] All of Rouget's demos are measured in seconds per frame on my machine as
> >>well. I suspect everybody over there is testing with developer machines
> >>with fancy hardware - though I would have thought a 2.1G Turion X2 with a
> >>Radeon HD3200 would have been good enough.
> >
> >Actually many of us test on phones these days.
>
> This is very much of a side-track the the discussion, but while not
> officially a demo and instead something we heavily touted as an
> official page in the last days, glow.mozilla.org has been slightly
> sluggish on my Core2 Duo Laptop, maybe because we don't support any
> hw accel on an open graphics stack (Linux + Intel drivers in this
> case)

Note that I have similar hardware and hadn't any particular slowness
with glow.mozilla.org.

> and completely unusable (didn't even get a single download
> number) on my phone (N900).
>
> Also, running all tests proved to be a "go for an hour of shopping
> or more and try to see if the failures could be related to your
> system" experience every time I tried - and I never saw a full test
> pass go green on any of my machines. But perhaps once again Linux is
> at the disadvantage there.

Again here, I have a totally different experience. I regularly run
xpcshell-tests, reftests, crashtests and jstestbrowser and really rarely
hit one or two of the multiple oranges that can be seen on linux
tinderboxes. In other words, it's green most of the time here, and once
in a while i see a small subset of the known oranges.

Mike

davidwboswell

unread,
Mar 25, 2011, 1:04:13 PM3/25/11
to
> New contributors are also much better at knowing their pain points than,
> well, people that are familiar. When we're lucky enough to get new
> contributors -- whether they are interns, new hires, or otherwise
> interested in the Mozilla community -- it would be nice to pay attention
> and document things that are barriers to entry. I've only been here a
> year, and already I've forgotten about my initial pain points.

I think this is a great idea. Doing a survey of people who have
recently become contributors, or people who have recently tried to
become contributors and didn't, would be very helpful.

FWIW, Dan Mosedale has done some surveys like this with the
Thunderbird community. There may be things he has found that are
general good ideas for any project.

David

It is loading more messages.
0 new messages