What gets landed for FF5?

classic Classic list List threaded Threaded
111 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

What gets landed for FF5?

Mike Shaver
On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Mike Beltzner
----- Original Message -----

> On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron <[hidden email]>
> 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),

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

L. David Baron
In reply to this post by Mike Shaver
On Tuesday 2011-03-22 09:21 -0700, Mike Shaver wrote:

> On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron <[hidden email]> 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/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Boris Zbarsky
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Mike Shaver
On Tue, Mar 22, 2011 at 9:41 AM, Boris Zbarsky <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Mike Beltzner
In reply to this post by Boris Zbarsky
----- 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Mark Banner-2
In reply to this post by Mike Shaver
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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Ehsan Akhgari
In reply to this post by Mike Beltzner
On 11-03-22 12:24 PM, Mike Beltzner wrote:

> ----- Original Message -----
>> On Mon, Mar 21, 2011 at 2:05 PM, L. David Baron<[hidden email]>
>> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Boris Zbarsky
In reply to this post by Mike Shaver
On 3/22/11 12:54 PM, Mike Beltzner wrote:
> ----- 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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Mike Beltzner
----- 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Steve Fink-4
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.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Jeff Hammel-2
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


On 03/22/2011 11:29 AM, Steve Fink wrote:

> 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.
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Joshua Cranmer-2
In reply to this post by Mike Beltzner
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?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Paul Biggar-3
On Tue, Mar 22, 2011 at 1:51 PM, Joshua Cranmer <[hidden email]> 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
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Dustin Mitchell
In reply to this post by Joshua Cranmer-2
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Christian Legnitto

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 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 :)

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Cameron Kaiser-2
In reply to this post by Mike Beltzner
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Robert O'Callahan-3
In reply to this post by Joshua Cranmer-2
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]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Robert O'Callahan-3
In reply to this post by Dustin Mitchell
I think we're over-exaggerating a bit here :-).

On Wed, Mar 23, 2011 at 10:48 AM, Dustin J. Mitchell <[hidden email]>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!

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]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: What gets landed for FF5?

Dustin Mitchell
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 6