Places and Firefox 2

12 views
Skip to first unread message

Michael Schroepfer

unread,
Apr 24, 2006, 1:00:08 AM4/24/06
to
As we have been preparing for the FF2 Alpha2 on May 9 it has become
increasingly clear that we do not have time to complete an
implementation of places that lives up to our standards of user
experience and quality. Places is a complex and exciting feature which
changes the way people use bookmarks, history, and navigate through
their private space of the web. Rather than rush it to market - we'd
prefer to spend the time it takes to get it right.

Thus, we are going to disable Places on the 1.8 branch and continue work
on the feature on the trunk for inclusion on a future release. This is
a difficult decision - but doing it this early in the release cycle
gives us the time to focus on delivering an extremely high quality FF2
in Q3 and gives Places the room it needs to develop into a truly
innovative feature.

To be clear - we're still focused on delivering Places as a truly
compelling end user feature in a future release. We're also confident
that the other features and enhancements slated for FF2 will provide a
great upgrade for 1.5 users and continue to be a compelling browser
choice for new users. Firefox 2 will improve security, tabbed browsing,
search, RSS/structured content discovery, performance, and extension
support. In order words, all the reasons people love Firefox will get
demonstrably better in this release.

At the Bon Echo meeting Tuesday at 11am we'll do a more in-depth review
of status of every feature area to figure out what else is at risk and
make sure we have all available effort focused on the critical areas.
So come prepared to talk about your feature area and plan for a longer
meeting than normal.

Cheers,

Schrep

Matt Nordhoff

unread,
Apr 24, 2006, 4:27:16 AM4/24/06
to

Without Places, Firefox 2.0 will have nothing new. Security
improvements, making the tabbed browsing UI worse ( :-P ), the search
XML backend and manager thingy, improved feed discovery, performance and
extension support... That's nothing. Even Places isn't very much, if
you're only thinking about the frontend as most users will. Users are
going to be extremely disappointed when they see nothing new or interesting.

mozilla.feedback has "I don't see any big differences" repeated
frequently over 2.0a1, and it had Places. From your post, Firefox 2.0
sounds like it should be called Firefox 1.6.
--
Matt Nordhoff
(aka Peng on IRC & the forums)

Matt Nordhoff

unread,
Apr 24, 2006, 4:57:54 AM4/24/06
to
On 04/24/06 04:27, Matt Nordhoff wrote:
> Without Places, Firefox 2.0 will have nothing new. Security
> improvements, making the tabbed browsing UI worse ( :-P ), the search
> XML backend and manager thingy, improved feed discovery, performance and
> extension support... That's nothing. Even Places isn't very much, if
> you're only thinking about the frontend as most users will. Users are
> going to be extremely disappointed when they see nothing new or
> interesting.
>
> mozilla.feedback has "I don't see any big differences" repeated
> frequently over 2.0a1, and it had Places. From your post, Firefox 2.0
> sounds like it should be called Firefox 1.6.

Wait, are session restore and the in-line spell checking still going to
be in 2.0?

If they are, I'll be okay with 1.7, but still not 2.0. They aren't an
immediate "Wow!" when you open the browser.

(And yes, I know I'm being harsh, and even small improvements are a good
thing and can take a good amount of work, but Firefox 2.0 just doesn't
seem like a 2.0.)

Matt Nordhoff

unread,
Apr 24, 2006, 10:35:07 AM4/24/06
to
On 04/24/06 04:57, Matt Nordhoff wrote:
> Wait, are session restore and the in-line spell checking still going to
> be in 2.0?
>
> If they are, I'll be okay with 1.7, but still not 2.0. They aren't an
> immediate "Wow!" when you open the browser.
>
> (And yes, I know I'm being harsh, and even small improvements are a good
> thing and can take a good amount of work, but Firefox 2.0 just doesn't
> seem like a 2.0.)

Okay, I retract my nastiness, but I still think that without Places,
Firefox 2.0 is somewhat disappointing. But then, most of the other
things don't really matter to me. Well, security and performance and
extension support do, but I don't have problems with them (except the
slowness of my huge amounts of bookmarks and history).

The session restore feature, I already use Session Manager and will
continue to, because the extension can be updated without the review
process and I can easily get those updates without having to download a
new build of Firefox.

The search stuff is nice, too. Using the XML format reduces the number
of files I have in searchplugins by half, and the format looks nicer
than the old one. (And importing them will make all the indentation and
stuff identical in each one. :-) )

And Places, well, at least it will be interesting. I'm back down to the
mozilla1.8.0 branch because I want to avoid it until it's fully working
and I've sorted out my duplicate bookmarks because Places'll screw 'em
up, but once I do that and have an hour or two where I can live without
being able to use Firefox while everything is imported, I'm game.

Meh. Whatever. I'm rambling more, but at least I'm being nicer. ;-)
Firefox 2.0 isn't seeming incredibly interesting, though.

steve....@gmail.com

unread,
Apr 24, 2006, 12:36:38 PM4/24/06
to
Yeah I'm all for this. Places has loads of potential that i'm sure will
get realised, but atm there's too many bugs filed against it in order
to give end users a highly polished experience for 2.0.

2.0 will still have a bunch of improvements, including:
* Visual Refresh
* Safebrowser anti-phising
* Inline spellcheck
* Session Management
* RSS handling improvements
* Extension/Themes UI change
* New search engine infrastructure and UI
* New installer
* Browser performance metric measurer
which is quite a few, and most of them something the end-user will be
able to see with their own eyes. Some ppl might say this isn't enough
to be worth calling it a 2.0 release, but for me it is, and a 2.0
release doesn't have to be a much-trumpeted affair.

schiller

unread,
Apr 24, 2006, 1:49:22 PM4/24/06
to
steve....@gmail.com wrote:
> a 2.0 release doesn't have to be a much-trumpeted affair.

What if you want to stack your browser advances up against the other
next-generation browsers soon to be released: IE7 and Opera9?

I don't know, going up a rev number is usually a big deal. I guess if
you put all total advances from 1.0 -> 2.0 it is a big deal. So now I
see why edging the release number from 1.1 to 1.5 last year was a wise
choice, because the step to 2.0 is not exactly earth-shattering. Only
problem is, it's been so long since I used Firefox 1.0 that I kind of
forget the advances that Firefox 1.5 brought.

Anyway, it's not like people are not going to upgrade (especially with
the auto-upgrade functionality in 1.5)... there will just be less of a
fuss in the blogosphere (and prepare yourselves for a few
"disappointed" reviews). Heck, Firefox 1.5 still beats IE7, from what
I've heard...

Hey, maybe they can get those recently checked-in SVG performance
improvements into 2.0...;)

Doron Rosenberg

unread,
Apr 24, 2006, 3:49:06 PM4/24/06
to
Will Firefox 2 ship the mozstorage (sqllite) engine then? It might be
worth it for extension authors to have it, even if the main product
doesn't use it.

Doron

Vladimir Vukicevic

unread,
Apr 24, 2006, 4:03:37 PM4/24/06
to
Yes, the plan is still for mozStorage to ship with Fx2 so that it's
available to extension authors. This should give a much nicer
alternative to RDF/XML for data storage.

Benjamin Smedberg

unread,
Apr 24, 2006, 4:07:51 PM4/24/06
to

How was that decided? Part of the codesize tradeoff for sqlite was the
removal of the full mork engine. Shipping both sounds like a silly idea
since the app won't be using sqlite at all (unless there are other
dependencies that I've missed).

--BDS

Myk Melez

unread,
Apr 24, 2006, 4:08:11 PM4/24/06
to Michael Schroepfer
Michael Schroepfer wrote:

> Thus, we are going to disable Places on the 1.8 branch and continue work
> on the feature on the trunk for inclusion on a future release.

Out of curiosity, how was this decision made? I would have thought
there would have been some discussion about it in this newsgroup and the
weekly meetings, but I don't recall any such discussion taking place.

-myk

Mike Connor

unread,
Apr 24, 2006, 4:23:14 PM4/24/06
to dev-pl...@lists.mozilla.org
I'm less concerned with codesize than with shipping a stronger
platform. There's also the strong possibility that we'll be supporting
a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.

-- Mike

Benjamin Smedberg

unread,
Apr 24, 2006, 4:34:39 PM4/24/06
to

Who is doing that work?

I am wary of shipping complex platform-level features that do not get
widespread "natural" testing, and have not received (IMO) sufficient
targeted testing in the field. The SQLite performance issues that were
turned up by the places work amplified my initial worry several times over.
Since we are certainly not going to be freezing the storage interfaces for
this cycle, I am very wary of shipping them or encouranging developers to
use them.

There are outstanding unresolved issues about how we plan to version the
SQLite data structures over time within profiles (most of which are
admittedly app-level issues, not platform-level issues), as well as
questions about whether and to what extent we should be supporting
multi-process access to the data. Unless there is a Firefox 2 feature that
requires the storage APIs, I do not think that "a stronger platform" is a
good reason to ship this code.

--BDS

schiller

unread,
Apr 24, 2006, 4:49:12 PM4/24/06
to

Mike Connor wrote:
> There's also the strong possibility that we'll be supporting
> a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>

Weird, I hadn't heard that this would be a possibility on any of the
planning meetings summaries or in the Firefox 2 Requirements wiki page.
What priority was that? In fact, seems that almost all the Places
stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
product requirements are complete"...

Brett Wilson

unread,
Apr 24, 2006, 4:51:36 PM4/24/06
to
We need to decide soon about sqlite being in or out. We need to change
some of the APIs around and make some things safer. If it's shipping in
2.0, I need to make this a priority. Otherwise, it will stay on the back
burner.

> I am wary of shipping complex platform-level features that do not get
> widespread "natural" testing, and have not received (IMO) sufficient
> targeted testing in the field. The SQLite performance issues that were
> turned up by the places work amplified my initial worry several times
> over.

I would come to exactly the opposite conclusion you have. Places
performs fine now, in some ways better than Mork. Any system requires
tuning to perform well. The previous history system no doubt had a lot
of performance work done on it to make it fast, and sqlite is no
different. I don't see this as a warning sign at all. (Perhaps some of
this feeling is a result of the early impression that was floating
around that sqlite would solve all our problems, which is clearly not
true.) We have produced a system that has been tested it to perform well
under constant use while you browse.


> There are outstanding unresolved issues about how we plan to version the
> SQLite data structures over time within profiles (most of which are
> admittedly app-level issues, not platform-level issues),

I would also like to see this discussion take place. At least we need a
plan, even if we don't actually do anything.

> as well as
> questions about whether and to what extent we should be supporting
> multi-process access to the data.

The decision is that we don't support this. Supporting it would kill a
lot of the performance. Maybe this decision wasn't made explicitly, but
it will take a lot of work that hasn't been planned and would give a
measurable performance hit no matter what, so I think the decision has
been made implicitly.

Brett

Mike Shaver

unread,
Apr 24, 2006, 5:11:39 PM4/24/06
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
On 4/24/06, Benjamin Smedberg <benj...@smedbergs.us> wrote:

> Mike Connor wrote:
> > I'm less concerned with codesize than with shipping a stronger
> > platform. There's also the strong possibility that we'll be supporting
> > a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>
> Who is doing that work?

jst and Neil Deakin, it's already underway. (See recent content team
minutes for more details, I expect.)

> I am wary of shipping complex platform-level features that do not get
> widespread "natural" testing, and have not received (IMO) sufficient
> targeted testing in the field. The SQLite performance issues that were
> turned up by the places work amplified my initial worry several times over.
> Since we are certainly not going to be freezing the storage interfaces for
> this cycle, I am very wary of shipping them or encouranging developers to
> use them.

Developers have been using the storage APIs for a long time now; since
the end of 2004 in calendar-land, and quite intensively with Places
since. That testing is what led to the revisions in the APIs and also
the commissioning of the sqlite performance work (which preserved API
compatibility at the mozStorage level, I believe).

sqlite itself has been tested quite extensively -- the rest of our
platform should be so lucky! -- so the only other element here is our
wrapping of it in the mozStorage APIs. Those APIs have had pretty
good testing proportionate to their scope, IMO.

I do not at all agree with the idea of not shipping things until
they're frozen. We have a terrible record of "predictive" API design,
and not many groups have good ones.

> There are outstanding unresolved issues about how we plan to version the
> SQLite data structures over time within profiles (most of which are
> admittedly app-level issues, not platform-level issues),

They are app-level issues, and I don't think that "best practices"
here are going to emerge until after people try various different
approaches to it in the wild, in extensions, on top of our storage
interfaces.

> as well as
> questions about whether and to what extent we should be supporting
> multi-process access to the data.

"should be supporting" isn't as interesting as "will support", and for
Fx2 our answer will likely be "don't" or "at your own peril;
synchronize out of band".

Mike

Brendan Eich

unread,
Apr 24, 2006, 5:18:48 PM4/24/06
to
What I think:

- Angst about Firefox 2 lacking a reason to exist without Places,
especially vis a vis IE7, is misplaced, if you will pardon the pun.
There are tons of good reasons to do a strong Firefox 2 upgrade to 1.5
this year, well before IE7 comes out -- some of these have already been
listed in this thread by others.

- Local storage based on the http://www.whatwg.org/ proposal should be
in Firefox 2. It wasn't planned early, but it looks like it will fit
easily, and the reward is big while Firefox can differentiate itself
against IE6. Again, Firefox 2 has a place in the stream of releases we
will make over the next few years in order to compete and to advance the
state of the open web. Making Firefox 2 all about Places is a mistake.

- There are other platform pieces being uplifted into Firefox 2, about
which shaver has led the planning. I'll let him jump in here.

While we should not be over-focused on IE7, the idea of sandwiching IE7
between continuously improving Firefox releases still wins over trying
to do one "big-bang", "matching" release.

More than any competitive strategy, it is vitally important that we
continuously improve the product and the platform soon and regularly.
Right now Firefox has >50% usage on "web 2.0"-ish sites. That market
share is pure leverage, which we should use to (a) keep improving user
and content author experiences; (b) keep the competition on *their* toes
-- which we are doing!

Avoiding all-or-nothing thinking, and big-bang mythical-man-month
last-minute-fix moves, are also Good Things (tm). Taking the time
needed to get Places right, adjusting the Firefox 2 bill of materials,
keeping on schedule, all shows mature judgment and realism. Huzzah to
all that -- we need more of it.

/be

Benjamin Smedberg

unread,
Apr 24, 2006, 5:24:45 PM4/24/06
to
Mike Shaver wrote:

> I do not at all agree with the idea of not shipping things until
> they're frozen. We have a terrible record of "predictive" API design,
> and not many groups have good ones.

I didn't say that... I said "shipping things that we're not also going to
use internally". There is a much higher incentive to keep backwards
compatibility or provide compatibility workarounds as the code matures if we
are using the code internally and it's "our problem".

> "should be supporting" isn't as interesting as "will support", and for
> Fx2 our answer will likely be "don't" or "at your own peril;
> synchronize out of band".

Sure, and expediency is a fine plan if you actually are planning on using
the feature, which was the general agreement six months ago when we decided
that we didn't have time to think about multi-process SQLite access for FF2.
But (modulo local-storage APIs) we don't have to bite that bullet, which
gives us the extra 3-6 months before FF3 closes to see if we can come up
with a good sharing solution before we're committed to a file format,
locking pattern, and API.

--BDS

Mike Shaver

unread,
Apr 24, 2006, 5:27:27 PM4/24/06
to schiller, dev-pl...@lists.mozilla.org
On 24 Apr 2006 13:49:12 -0700, schiller <code...@gmail.com> wrote:
>
> Mike Connor wrote:
> > There's also the strong possibility that we'll be supporting
> > a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>
> Weird, I hadn't heard that this would be a possibility on any of the
> planning meetings summaries or in the Firefox 2 Requirements wiki page.

http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-04#Infrastructure:_Platform_Uplift
mentioned it, and
http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-11#Infrastructure:_Platform_Uplift
as well, plus the content meeting minutes from
http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/bc6c8b5485141c97/cc7931a1cef8c2ac#cc7931a1cef8c2ac

> What priority was that?

It hasn't had an explicit priority set, we're still in the
"investigative initial development" stage. Is that important?

> In fact, seems that almost all the Places
> stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
> product requirements are complete"...

So? Are you trying to say that we are in violation of some contract?
Many items have had their priorities adjusted as we learned more about
them or considered the tradeoffs further, as is the case for virtually
every piece of software I've ever worked on.

If you're just pointing out that the priorities changed, and that what
we once thought was going to be central to Firefox 2 is no longer
something we're comfortable holding the release for, then you're just
repeating what Schrep posted to start this thread.

It would be helpful, possibly, for you to finish the sentence, since I
don't think the ellipsis is clear enough to make your point plain.
(It's not to me, at least.)

If you have input on the prioritization of Fx2 elements, please do
join us on the weekly call tomorrow to share it, or add it to the
agenda page beforehand.

Mike

L. David Baron

unread,
Apr 24, 2006, 5:28:45 PM4/24/06
to dev-pl...@lists.mozilla.org
On Sunday 2006-04-23 22:00 -0700, Michael Schroepfer wrote:
> Thus, we are going to disable Places on the 1.8 branch and continue work
> on the feature on the trunk for inclusion on a future release. This is

So, what's going to happen to the portion of our testing community that
has migrated their primary profiles to places-based storage? Will they
just lose all the changes they've made to their bookmarks since the
switch to places? When we switch back to places, will they lose all the
changes they make from now until then?

We don't want to make things too painful for our bleeding-edge testers
or pretty soon we won't have any.

-David

--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation

Mike Connor

unread,
Apr 24, 2006, 5:35:12 PM4/24/06
to dev-pl...@lists.mozilla.org
schiller wrote:
> Mike Connor wrote:
>
>> There's also the strong possibility that we'll be supporting
>> a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.
>>
>>
>
> Weird, I hadn't heard that this would be a possibility on any of the
> planning meetings summaries or in the Firefox 2 Requirements wiki page.
>

Gecko 1.8.1 features are separately tracked from the Firefox 2 app
planning. It is not a requirement from the application end, other than
the generic item for Gecko 1.8.1 uplift and improvements.

> What priority was that? In fact, seems that almost all the Places
> stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
> product requirements are complete"...
>

Well, the conversation around that was "if we're doing Places in this
release, we need all of these things for it to be done" which is why
they were all P1s. If something turns out to be too risky, in terms of
stability and/or schedule impact, we need to reassess things. The
requirements will evolve and change for any release based on what is
possible and what is not, at that point in time. Features and their
importance are relative to release dates, and we based the feature list
around a Q3 release. With a possible slip until next year to get Places
up to the right level of quality in Fx2, and a planned Q1 release for
Firefox 3, moving the feature to Firefox 3 isn't a big change in when
the feature should get to market, it just means others will get there
earlier.

-- Mike

Darin Fisher

unread,
Apr 24, 2006, 5:42:50 PM4/24/06
to dev-pl...@lists.mozilla.org
On 4/24/06, L. David Baron <dba...@dbaron.org> wrote:
> On Sunday 2006-04-23 22:00 -0700, Michael Schroepfer wrote:
> > Thus, we are going to disable Places on the 1.8 branch and continue work
> > on the feature on the trunk for inclusion on a future release. This is
>
> So, what's going to happen to the portion of our testing community that
> has migrated their primary profiles to places-based storage? Will they
> just lose all the changes they've made to their bookmarks since the
> switch to places? When we switch back to places, will they lose all the
> changes they make from now until then?
>
> We don't want to make things too painful for our bleeding-edge testers
> or pretty soon we won't have any.

If we do nothing, then they will "lose" any changes they made to their
bookmarks since running a places-enabled build. That may be a pill we
should swallow for simplicity sake. Going back to places, we can make
matters better by renaming the "history and bookmarks" sqlite file.

-Darin

Mike Connor

unread,
Apr 24, 2006, 5:47:14 PM4/24/06
to dev-pl...@lists.mozilla.org
L. David Baron wrote:
> On Sunday 2006-04-23 22:00 -0700, Michael Schroepfer wrote:
>
>> Thus, we are going to disable Places on the 1.8 branch and continue work
>> on the feature on the trunk for inclusion on a future release. This is
>>
>
> So, what's going to happen to the portion of our testing community that
> has migrated their primary profiles to places-based storage? Will they
> just lose all the changes they've made to their bookmarks since the
> switch to places? When we switch back to places, will they lose all the
> changes they make from now until then?
>

Given that there isn't an exporter, those recent bookmarks won't be
accessible in branch builds. If they're following the branch, they've
quite possibly had to nuke their sqlite file a couple times to make
stuff work right (I actually need to bite that bullet myself), so its
nothing really new.
Best case, someone could write an exporter soon, and they could run
that from a trunk build...

> We don't want to make things too painful for our bleeding-edge testers
> or pretty soon we won't have any.
>

Agreed in principle, but I'm not sure what you're saying we should do
here. Write a sqlite->html converter and ship that in the non-places
builds? There's only so much we can do here, its just going to suck for
some people, but they can always run a trunk build and recover that
bookmark, its not like the date is _gone_. They can at least drag the
bookmarks to Notepad or something and get the URLs.

-- Mike

Mike Shaver

unread,
Apr 24, 2006, 5:51:17 PM4/24/06
to dev-pl...@lists.mozilla.org
On 4/24/06, L. David Baron <dba...@dbaron.org> wrote:
> So, what's going to happen to the portion of our testing community that
> has migrated their primary profiles to places-based storage? Will they
> just lose all the changes they've made to their bookmarks since the
> switch to places? When we switch back to places, will they lose all the
> changes they make from now until then?

I believe the Places bookmark-export code has just landed, or is
reviewed and is ready to land, so that problem may be lessened.

Mike
(I could be totally wrong, though)

Chris Ilias

unread,
Apr 24, 2006, 5:58:18 PM4/24/06
to
_Mike Shaver_ spoke thusly on 24/04/2006 5:51 PM:

> I believe the Places bookmark-export code has just landed, or is
> reviewed and is ready to land, so that problem may be lessened.
>
> Mike
> (I could be totally wrong, though)

https://bugzilla.mozilla.org/show_bug.cgi?id=318057
https://bugzilla.mozilla.org/show_bug.cgi?id=327925
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)

steve....@gmail.com

unread,
Apr 24, 2006, 6:09:42 PM4/24/06
to
> I believe the Places bookmark-export code has just landed, or is
> reviewed and is ready to land, so that problem may be lessened.
>
> Mike

Yeah, it's landed on trunk and 2.0 branch:
https://bugzilla.mozilla.org/show_bug.cgi?id=318057 --
[Firefox:Places]-bookmarks.html exporter [All]

Brett Wilson

unread,
Apr 24, 2006, 6:54:35 PM4/24/06
to
Mike Connor wrote:
> Given that there isn't an exporter, those recent bookmarks won't be
> accessible in branch builds. If they're following the branch, they've
> quite possibly had to nuke their sqlite file a couple times to make
> stuff work right (I actually need to bite that bullet myself), so its
> nothing really new. Best case, someone could write an exporter soon, and
> they could run that from a trunk build...

I checked in the bookmarks exporter today. It's in the File menu in the
places organizer window.

Brett

Brett Wilson

unread,
Apr 24, 2006, 7:08:40 PM4/24/06
to
Brett Wilson wrote:
> I checked in the bookmarks exporter today. It's in the File menu in the
> places organizer window.

My bad. Apparently 1.5 doesn't like the format. Filed as:
https://bugzilla.mozilla.org/show_bug.cgi?id=335308

Brett

Brett Wilson

unread,
Apr 24, 2006, 7:31:35 PM4/24/06
to

OK, exported files should be readable by 1.5 now.

Brett

schiller

unread,
Apr 24, 2006, 8:18:08 PM4/24/06
to

Mike Shaver wrote:

> http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-04#Infrastructure:_Platform_Uplift
> mentioned it

Thanks, Mike. I missed that. Sometimes that low-hanging fruit is
where it's at. Plus, I think web developers love getting surprises
like this...

> > What priority was that?
>
> It hasn't had an explicit priority set, we're still in the
> "investigative initial development" stage. Is that important?

I'm not doing the planning or the development, I'm just an observer
asking a question. It seems that in order to pursue something new that
you'd want to attach a priority to it. It would only be of minor
importance to me if it was lower priority work being pursued instead of
higher priority work (but no one has stated this).

>
> > In fact, seems that almost all the Places
> > stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
> > product requirements are complete"...

My ellipsis is dangling, it's true ;) If the criteria is that all P1s
are to be complete, then either Places is being de-prioritized or the
release criteria is changing (otherwise you'd push back Firefox 2.0).
As you state, the answer is it's being de-prioritized because of its
complexity, so i appreciate your clarification, which may have been
obvious to you, just not to me. Everything else P1 is still a lock for
Firefox 2.0.

>
> So? Are you trying to say that we are in violation of some contract?
> Many items have had their priorities adjusted as we learned more about
> them or considered the tradeoffs further, as is the case for virtually
> every piece of software I've ever worked on.

Of course priority adjustments will happen. Every piece of software
I've worked on has also suffered the same fate. The best laid plans of
mice and men... (woops there's that ellipsis again)

All in all, please don't get defensive. I enjoy the open-source, open
planning nature of Mozilla and I appreciate the "fly-on-the-wall"
opportunity. When the flies start to get loud, bring out the
flyswatter. ;)

Regards,
Jeff

Brendan Eich

unread,
Apr 24, 2006, 9:24:13 PM4/24/06
to Benjamin Smedberg
Benjamin Smedberg wrote:

> Sure, and expediency is a fine plan if you actually are planning on
> using the feature, which was the general agreement six months ago when
> we decided that we didn't have time to think about multi-process SQLite
> access for FF2. But (modulo local-storage APIs) we don't have to bite
> that bullet, which gives us the extra 3-6 months before FF3 closes to
> see if we can come up with a good sharing solution before we're
> committed to a file format, locking pattern, and API.

You know, like: worse is better, and stuff.

Seriously, we do not gain by such ambitious designing in advance of use
cases. Firefox 2 does not need to support MP access to any sqlite db
used for local web app storage, and I doubt we ever will want that. It
costs a lot.

But whatever the case down the road, getting local storage surfaced in
Firefox 2, rather than holding it for 3 in the hope (how, exactly?) of
making MP access cheap enough, and correct to boot, is "better is
better" thinking. It's overkill that underserves (underserving to zero)
by delaying, and delay is the best form of denial.

If we can get single-process sqlite in Firefox 2, then rev the APIs for
3 based on more substantive feedback from extension authors than we
would get from alpha-3 releases, then I think everyone wins.

/be

edh...@gmail.com

unread,
Apr 24, 2006, 11:58:14 PM4/24/06
to
When 2.0a1/a2 builds start showing up with Places disabled, would there
be a way for us nightly testers to enable it?

Being able to do this from a zip build would be nice, since I share
this computer with someone who needs a plain-vanilla version for work.

Mike Beltzner

unread,
Apr 25, 2006, 12:21:45 AM4/25/06
to Myk Melez, dev-pl...@lists.mozilla.org
On 4/24/06, Myk Melez <m...@mozilla.org> wrote:
> Out of curiosity, how was this decision made? I would have thought
> there would have been some discussion about it in this newsgroup and the
> weekly meetings, but I don't recall any such discussion taking place.

Excellent question, Myk. I'm sure that we'll go over it in the meeting
tomorrow, but late last week, mconnor and ben started to look over the
buglist for Places while doing their SWAGs and began to realize that
in order to implement the feature properly, they were really going to
need more time. So they took a good hard look at what sort of delay
they would need, and what the pros and cons would be of pulling it,
and then came to the decision in consultation with engineering and
product leads at MoCo that it would be best to de-prioritize and pull
it from the branch.

And that's where we're at, and that's what we'll be talking about at
tomorrow's meeting. We all want what's best for the product, and it's
become clear that to get Places to a point where it's kick-ass enough
to be part of Firefox, we need more time than the Fx2 schedule allows.
It's a lot of work, and I for one am glad that the decision came down
to quality and looking out for the user.

cheers,
mike

(ps: I hope that this also gets us talking about how to plan and scope
releases better, but that conversation would most profitably done
*after* tomorrow's meeting, I think ;)

--
/ mike beltzner / user experience lead / mozilla corporation /

Mike Beltzner

unread,
Apr 25, 2006, 12:26:17 AM4/25/06
to edh...@gmail.com, dev-pl...@lists.mozilla.org
On 24 Apr 2006 20:58:14 -0700, edh...@gmail.com <edh...@gmail.com> wrote:
> When 2.0a1/a2 builds start showing up with Places disabled, would there
> be a way for us nightly testers to enable it?

The best thing to do would be to run Minefield (trunk) and point it at
a different profile (you can just make a new profile, copy the entire
contents of your old profile into it, and presto, instant migration).
As I understand it, the team will no longer be landing Places patches
on the branch, so if you want to stay up to date with developments,
you'll need to be running the trunk code.

If you really want to re-enable it on your branch builds,
ac_add_options --enable-places might still work. Dunno. bsmedberg?

> Being able to do this from a zip build would be nice, since I share
> this computer with someone who needs a plain-vanilla version for work.

Minefield will install into a different directory, so you should be
able to share pretty sucessfully. Just change your shortcut (assuming
Windows) to point to ".../firefox.exe -P <newProfileName>" to get the
places-enabled profile.

cheers,
mike

Vladimir Vukicevic

unread,
Apr 25, 2006, 3:17:56 AM4/25/06
to
Benjamin D. Smedberg wrote:
> Sure, and expediency is a fine plan if you actually are planning on using
> the feature, which was the general agreement six months ago when we decided
> that we didn't have time to think about multi-process SQLite access for FF2.
> But (modulo local-storage APIs) we don't have to bite that bullet, which
> gives us the extra 3-6 months before FF3 closes to see if we can come up
> with a good sharing solution before we're committed to a file format,
> locking pattern, and API.

I don't see how this is relevant; without Places, we're not placing any
profile data into storage. Extensions will be able to create and use
their own databases, and nothing more; multi-process sqlite access
(directly, through sqlite) does not affect them. Any schemes for
multi-process database access will be another layer on top (e.g.
various token-passing schemes that were discussed a while back); any
multi-process locking will be part of this system. The APIs will also
only be exposed to extension and platform app authors, not to general
web content; so even given a drastic need to make an incompatible API
change, it won't have been the first time we've needed to do that.

Giving extension and app authors an alternative to RDF/XML (mork isn't
accessible from JS) for structured data storage is a huge
platform-level win, IMO.

(We should probably move this discussion for another thread, since it
doesn't directly relate to Places.)


- Vlad

Axel Hecht

unread,
Apr 25, 2006, 4:40:48 AM4/25/06
to

Myk, does this impact microsummaries, too?

Axel

Jonas Sicking

unread,
Apr 25, 2006, 4:52:19 AM4/25/06
to
Mike Beltzner wrote:
> On 4/24/06, Myk Melez <m...@mozilla.org> wrote:
>> Out of curiosity, how was this decision made? I would have thought
>> there would have been some discussion about it in this newsgroup and the
>> weekly meetings, but I don't recall any such discussion taking place.
>
> Excellent question, Myk. I'm sure that we'll go over it in the meeting
> tomorrow, but late last week, mconnor and ben started to look over the
> buglist for Places while doing their SWAGs and began to realize that
> in order to implement the feature properly, they were really going to
> need more time. So they took a good hard look at what sort of delay
> they would need, and what the pros and cons would be of pulling it,
> and then came to the decision in consultation with engineering and
> product leads at MoCo that it would be best to de-prioritize and pull
> it from the branch.
>
> And that's where we're at, and that's what we'll be talking about at
> tomorrow's meeting. We all want what's best for the product, and it's
> become clear that to get Places to a point where it's kick-ass enough
> to be part of Firefox, we need more time than the Fx2 schedule allows.
> It's a lot of work, and I for one am glad that the decision came down
> to quality and looking out for the user.

Honestly, I am actually impressed with how this was handled. The people
responsible for this feature took the hard decision that the feature
won't be ready by the time it needs to in order to get into the next
release. That decision doesn't need to involve everyone, just the people
responsible for writing the code or the people responsible for the release.

Of course, if we don't agree with the decision we could try to get it
changed, but I haven't heard a lot of that.

/ Jonas

Myk Melez

unread,
Apr 25, 2006, 12:44:08 PM4/25/06
to Mike Beltzner
Mike Beltzner wrote:

> We all want what's best for the product, and it's
> become clear that to get Places to a point where it's kick-ass enough
> to be part of Firefox, we need more time than the Fx2 schedule allows.
> It's a lot of work, and I for one am glad that the decision came down
> to quality and looking out for the user.

Sure, I understand the reasoning, and I want the same good things for
Firefox. I was only perplexed by the lack of public discussion about
the issue in advance of a decision, especially given the productive
public discussions about these kinds of issues that we've been having in
this newsgroup and at the weekly meetings over the last few months.

-myk

Myk Melez

unread,
Apr 25, 2006, 12:49:41 PM4/25/06
to Axel Hecht
Axel Hecht wrote:

> Myk, does this impact microsummaries, too?

The microsummaries service stores data in annotations, and bookmark
views need to be modified to support them, so switching back to the old
system on the branch does affect microsummaries.

I looked at what it would take to get microsummaries working on the old
bookmarks code, and it looks doable (storing the data in RDF properties
instead of annotations, and making the old personal toolbar view support
microsummaries).

I suspect I can even write a single patch that works with both places
and the old code. But it makes landing before a2 more uncertain. I'll
see what I can do.

-myk

hold...@gmail.com

unread,
Apr 25, 2006, 1:11:08 PM4/25/06
to
Why not just push back the FF2 release? Yes, you'll miss the target for
IE7, but I think a substatial release is more important than a "Hey!
We're still working!" one. I think you'll get reemed by the press for
not putting out what you promised.

nrth...@gmail.com

unread,
Apr 25, 2006, 1:23:39 PM4/25/06
to
Vladimir Vukicevic wrote:
> I don't see how this is relevant; without Places, we're not placing any
> profile data into storage. Extensions will be able to create and use
> their own databases, and nothing more ...
>
> <snip>
>
> - Vlad

Isn't form data in formhistory.sqlite now ?

Brad Fults

unread,
Apr 25, 2006, 1:27:48 PM4/25/06
to
100% agreed without reservation.

This will be one of the most underwhelming 2.0 releases in recent
software history from a consumer's point of view.

I would much rather wait another 6 months or a year for a worthy 2.0
than see 1.6 shipped as "2.0" when it introduces no new large features
at all. This is the old religious argument about version numbers, but
most software vendors (and I) agree that a major version increment
means *at least* large new features, if not huge changes that break
backwards compatibility (e.g. 1.9 trunk).

schiller

unread,
Apr 25, 2006, 1:53:12 PM4/25/06
to

Brad Fults wrote:
> This will be one of the most underwhelming 2.0 releases in recent
> software history from a consumer's point of view.
>
> I would much rather wait another 6 months or a year for a worthy 2.0
> than see 1.6 shipped as "2.0" when it introduces no new large features

The problem with this is the pain that will exist in having three
separate load lines, 1.8, 1.8.1 and the trunk. A 6-month delay in 2.0
would question why do the 1.8.1 branch at all, just release the trunk
when it's ready next year...

No, after thinking about it my vote is for sticking to the plan and
releasing something of high quality this year. A high quality visual
refresh will go along way with some people. Changes to feed and theme
management will also be something to talk about.

Anyway, the sooner developers focus on the trunk, the better.

Robert Sayre

unread,
Apr 25, 2006, 2:11:50 PM4/25/06
to Myk Melez, Mike Beltzner
Myk Melez wrote:
>
> Sure, I understand the reasoning, and I want the same good things for
> Firefox. I was only perplexed by the lack of public discussion about
> the issue in advance of a decision, especially given the productive
> public discussions about these kinds of issues that we've been having in
> this newsgroup and at the weekly meetings over the last few months.

I've found group decision-making to be a lot less productive than group
design and issue tracking. Sorry if this comes off snarky, but if the
product leads feel a feature should be postponed, I don't think they
need to waste everyone's time pretending to include the entire Internet
in the decision. I'm happy to get advance notice and decision reports.

-Rob

Myk Melez

unread,
Apr 25, 2006, 2:25:52 PM4/25/06
to Robert Sayre, Mike Beltzner
Robert Sayre wrote:

> I've found group decision-making to be a lot less productive than group
> design and issue tracking.

I'm not suggesting we make decisions as a group, only that we discuss
the issues as a group before the product leads make the decisions.

-myk

Boris Zbarsky

unread,
Apr 25, 2006, 3:22:47 PM4/25/06
to
Michael Schroepfer wrote:
> Thus, we are going to disable Places on the 1.8 branch and continue work
> on the feature on the trunk for inclusion on a future release.

Are there extant places bugs that would block a trunk alpha? It would be good
to identify them so that we can get them fixed in the next month or so...

-Boris

Axel Hecht

unread,
Apr 25, 2006, 5:25:53 PM4/25/06
to

I think a posting like "the heads of Firefox intend to propose pulling
places on the next meeting on tuesday for ... reasons" would have been
the same thing in terms of workload, without sounding so obscure.

But, as I said, it'd be the same thing, so why worry now.

Axel

Brett Wilson

unread,
Apr 25, 2006, 5:41:43 PM4/25/06
to

That's places only. We can turn that on or off independent of places,
however, and it's relatively low risk. But becuase it offers no visible
benefit, I don't think it would be worthwhile to turn on with any risk
at all.

We did that so we can get rid of Mork, which is the old database, to
free up space for strorage in the download.


Brett Wilson

unread,
Apr 25, 2006, 5:44:30 PM4/25/06
to

Maybe, but I doubt we'll get around to retargeting everything until
after 2.0a2. I think it's in a pretty good state. It will be much better
than the 2.0a1 release we already did, and I'm not sure the trunk alpha
requires better quality than the last one.

Brett

Håkan Waara

unread,
Apr 25, 2006, 6:52:35 PM4/25/06
to
One idea to avoid this situation in the future could be to only use
codenames during the development phase, even until the late stages of
it, and then decide on a version number when you have something that is
really starting to materialize.

Right now, whether anyone wants it or not, there is a big hype about
2.0 this and 3.0 that. If the features for the "next release" would be
added "lazily" - in programming terms - then there would be a natural
pressure on developers to make their features stable and good-looking
enough for the upcoming release.

/Håkan

Brendan Eich

unread,
Apr 25, 2006, 7:25:35 PM4/25/06
to Myk Melez, Robert Sayre, Mike Beltzner

I don't buy it in this case, or in many others -- even if the group is
just "discussing".

First, there's a fair amount of potential individual and group
sensitivity inherent in any decision to defer a major feature, both on
the part of the people working on the feature, and on the part of the
people managing the release. That may involve some amount of
negotiation, persuasion, etc. (perhaps not all seven stages of grief,
let's hope ;-). That is not best done in public.

Second, once that more sensitive and necessarily non-public decision
process has been "done" among the critical players, there is not much
point in going through the motions of soliciting public feedback as if
it would change the decision.

(At least not in this case. If the subject were a matter of great
unknowns or controversies about the facts before us, and it seemed
likely that newcomers or "outside" experts could shed light and resolve
a vexing dilemma, then maybe. Such a scenario is not credible in this
case, or in many like it that come to mind. There's no way around the
Mythical Man Month.)

Third, the peers with standing to discuss and debate in advance of a
decision being "virtually made" are generally the people included in the
less-than-public talk, in this case and most others. I do not believe
someone was left out. I do not believe that some valuable newcomer --
whom I *do* believe exists in spades, don't get me wrong -- is thereby
"left out".

(OTOH, if *you* felt left out, that's different! It may have been wrong
not to include you. But I am not sure how the outcome would have been
different. That's probably cold comfort, and it may well not justify
leaving you out, of course.)

The bottom line is this: It is truly not "everyone's business" to
discuss every decision before it is made, if there is to be meaningful
ownership of modules, products, and releases.

Let me repeat that: ownership implies subsidiary authority to decide
things, sometimes with public discussion first, sometimes without -- and
it's usually up to the owners to dial in the right amount of public
pre-decision discussion.

I am not saying that all decisions should happen in non-public venues,
and then be announced as if from on high. But it does not follow that
all decisions must be discussed in public in advance of being "made",
either. Often a fait accompli is better than a false dialog, especially
if the outcome is over-determined. (Ben and others may disagree with my
opinion here.)

For one thing, and this has been true over and over in the history of
the Mozilla project, discussing almost every decision leads to a false
sense of entitlement, and to a pretense that the relevant owners and
leaders really have not decided what they have in fact already decided
to do.

(Examples that come to mind go back to the dawn of the project. Even
though drivers mishandled the appeal process, I would cite the MNG
decision of the imglib owners as a good example of how decisions need
not *necessarily* be discussed in public before being made.)

Another point: I think I agree with Robert Sayre, that public design
tracking is more important than globally-public design discussions for
all the pieces of the system. As for "issue" (in the vogue sense of
"problem", as in "Houston, we have one" ;-)) tracking, that's even more
often best done without first publicly re-discussing the near-decision
already made by the principal owners. And that's what happened here, it
seems to me.

My 2+ cents.

/be

Brendan Eich

unread,
Apr 25, 2006, 7:34:50 PM4/25/06
to hold...@gmail.com


Who knows what the press will do? We can't control that, except by
delivering value to Firefox users, which should be our focus.

But what you propose is a recipe for being late, bloated *and* buggy.
Here's how it happens:

* We missed with a big feature (but not the only valuable feature!),
let's slip to give it more time.

* Let's put more people on it. Read Fred Brook's "The Mythical Man
Month" if you haven't.

* Wait, it's still not done, still not at Firefox 1.5 feature parity,
and we are slipping past IE7 -- we must have *other, whizzy* features to
compete!

* Repeat from the top.

This has been done over and over in the software industry ([1]). It's
pure folly. Don't propagate it.

/be

[1] One good writeup, from one of my past lives (and too often, such a
post mortem is simply not done, or if done is hidden behind a firewall):
http://yarchive.net/risks/sgi_irix.html

Myk Melez

unread,
Apr 25, 2006, 10:08:53 PM4/25/06
to Brendan Eich, Robert Sayre, Mike Beltzner
Brendan Eich wrote:

> First, there's a fair amount of potential individual and group
> sensitivity inherent in any decision to defer a major feature, both on
> the part of the people working on the feature, and on the part of the
> people managing the release. That may involve some amount of
> negotiation, persuasion, etc. (perhaps not all seven stages of grief,
> let's hope ;-). That is not best done in public.

Sure, but there's no reason for this part of the discussion to be the
entire conversation. We could still bring the issue into public forums
once the sensitive private conversations have taken place.


> Second, once that more sensitive and necessarily non-public decision
> process has been "done" among the critical players, there is not much
> point in going through the motions of soliciting public feedback as if
> it would change the decision.

Sure, if we're really just going through the motions without actually
caring about the response. But I'm wary of us assuming our plans won't
benefit from community input. I think we should assume they will,
unless we have very good reason to believe otherwise, and take responses
seriously.


> Third, the peers with standing to discuss and debate in advance of a
> decision being "virtually made" are generally the people included in the
> less-than-public talk, in this case and most others. I do not believe
> someone was left out. I do not believe that some valuable newcomer --
> whom I *do* believe exists in spades, don't get me wrong -- is thereby
> "left out".

If there are spades of valuable newcomers, then I think we will benefit
from including them in the discussion, even once a decision is
"virtually made," and even if we're making the right decision. At the
very least, we'll get additional reinforcement that we're doing the
right thing, and community members will have a chance to distinguish
themselves with useful feedback.


> (OTOH, if *you* felt left out, that's different! It may have been wrong
> not to include you. But I am not sure how the outcome would have been
> different. That's probably cold comfort, and it may well not justify
> leaving you out, of course.)

I was left out, but that's not the issue (including me probably wouldn't
have changed anything, especially since I agree with the decision, and
it's unclear that I had anything to contribute in this case).

The issue is that this project has taken valuable strides in the last
few months to include the community in its planning process by
discussing significant planning issues in the newsgroups and the weekly
meetings, and we shouldn't regress those improvements by now making some
planning decisions completely in private without a very good reason for
doing so (which, as far as I can tell, is not the case here).

-myk

Mike Connor

unread,
Apr 26, 2006, 12:01:49 AM4/26/06
to dev-pl...@lists.mozilla.org
Myk Melez wrote:
> Brendan Eich wrote:
>
>> First, there's a fair amount of potential individual and group
>> sensitivity inherent in any decision to defer a major feature, both
>> on the part of the people working on the feature, and on the part of
>> the people managing the release. That may involve some amount of
>> negotiation, persuasion, etc. (perhaps not all seven stages of grief,
>> let's hope ;-). That is not best done in public.
>
> Sure, but there's no reason for this part of the discussion to be the
> entire conversation. We could still bring the issue into public
> forums once the sensitive private conversations have taken place.
>

If the people working on the feature and the people managing the release
agree that the feature isn't going to make it, I'm not sure what
discussion would be productive here. The only possible question is
whether to delay the release until the feature is ready, but that's a
trap, as Brendan has pointed out repeatedly (and I will join him in
seeking to avoid that trap). If there's a benefit from adding another
feedback cycle (that offsets the cost of the delay in moving on the
decision), great, but I don't see a case where one exists here.

> The issue is that this project has taken valuable strides in the last
> few months to include the community in its planning process by
> discussing significant planning issues in the newsgroups and the
> weekly meetings, and we shouldn't regress those improvements by now
> making some planning decisions completely in private without a very
> good reason for doing so (which, as far as I can tell, is not the case
> here).

I believe people not directly involved in managing the release or
developing a feature will not have a lot of relevant insight into
whether a feature is going to miss a release. If it is going to miss
the release, the community can't change the outcome (c.f. The Mythical
Man-Month) and can only agitate for delaying the release. If we are
committed to shipping regular releases without gating on any single
feature, then the outcome will not change, so what does a discussion
with a predetermined outcome do, other than possibly make the situation
worse by invoking essentially pointless discussion?

Getting feedback on general plans/priorities/design is positive and we
need to continue to do that. And we will continue to bring people into
the folds of the ownership model as they develop into the roles. As
Brendan indicated, if a decision will benefit from public feedback
before it is made, we need to make sure that feedback is sought, but
that will not always be the case. We need to avoid dogmatic principles
around openness, and take the highest-value path wherever possible.

-- Mike

nrth...@gmail.com

unread,
Apr 26, 2006, 4:56:57 AM4/26/06
to
Brett Wilson wrote:
> > Isn't form data in formhistory.sqlite now ?
>
> That's places only. We can turn that on or off independent of places,
> however, and it's relatively low risk. But becuase it offers no visible
> benefit, I don't think it would be worthwhile to turn on with any risk
> at all.
>
> We did that so we can get rid of Mork, which is the old database, to
> free up space for strorage in the download.

So testers will end up with an export option for bookmarks, but not
history or form data. I guess I can live with that, but the loss of
history is a pain.

Brendan Eich

unread,
Apr 26, 2006, 6:45:23 PM4/26/06
to
Myk Melez wrote:

> The issue is that this project has taken valuable strides in the last
> few months to include the community in its planning process by
> discussing significant planning issues in the newsgroups and the weekly
> meetings, and we shouldn't regress those improvements by now making some
> planning decisions completely in private without a very good reason for
> doing so (which, as far as I can tell, is not the case here).


I don't buy it, and I gave my reasons. You seem to put more value in a
rote "discussion" after a decision has actually been made than I do.

I also don't believe that it is always automatically "regressive" to
decide things among a quorum of owners and peers, and I gave reasons for
that opinion. The owners and peers are not everyone, and "everyone"
does not own the particular valuables in question. Everyone does not
need to see all the sausage-making details of decision-making to assent
to the value of ownership, or to support the particular owners, for
every decision.

A few bad decisions can call ownership into question, for sure. But
this was not an example of such a bad decision. And even several poor
decisions by themselves would not call much into question, if the
owner(s) took corrective actions when the decisions were questioned.

As Robert Sayre put it, ability to track decisions in the open matters
more than details of the decision making being open from the get-go.
That means the rationale must be clear, once the decision has been made.
That happened here.

Anyway, I've written enough on this. What do others think?

/be

Mike Beltzner

unread,
Apr 27, 2006, 1:02:55 AM4/27/06
to Brendan Eich, dev-pl...@lists.mozilla.org
On 4/26/06, Brendan Eich <bre...@meer.net> wrote:
> I don't buy it, and I gave my reasons. You seem to put more value in a
> rote "discussion" after a decision has actually been made than I do.

I get the impression -- yet Myk should really speak for himself --
that the issue isn't as much with this particular instance, as opposed
to the idea that somewhere there are choices being made about what
issues are or are not discussed broadly before decisions are more or
less made.

My personal take on this is that we need that system for speed. There
are people who are active in the day to day management of this
particular release, and they have, in my opinion, earned our trust and
should therefore have the discretion to determine who should be
involved in making this sort of decision. This is not to say that they
have carte blanche, and as Sayerer (and Brendan) point out, the very
fact that their decisions are made public and put out in fora like
this for comment shows that they are looking to involve the community
and take their lumps if the decision can be demonstrated to have been
the wrong one.

> does not own the particular valuables in question. Everyone does not
> need to see all the sausage-making details of decision-making to assent
> to the value of ownership, or to support the particular owners, for
> every decision.

Agreed wholeheartedly. To do otherwise would slow us down to a point
where we couldn't use our breadth and speed appropriately.

cheers,
mike

Axel Hecht

unread,
Apr 27, 2006, 7:07:24 AM4/27/06
to

My impression is that few suggested an open discussion on pulling
places. Mike posted the decision on Sunday-Monday, there is a scheduled
conf call with 15-20 people that already did the prioritization work for
fx2 on every Tuesday. That groups has reliably worked on profound
proposals of feature owners in the past, giving usable feedback and
adjustments on some of it.

In this particular case, there was an established way between a sunday
coffee table and everbody's mother ranting.

The meeting did have the important discussion, like, what we could do
with those coders that were planned to drive places to a2 for a2.

Still, I'd prefer the post-mortem of this to include all readily
available options, which was one more than just owners or everybody.

Practical difference? Probably zilch, given that everybody on that
call/meeting knew for the past weeks that places approached borderline,
at least that is my perception.

Axel

Ben Goodger

unread,
Apr 28, 2006, 12:56:31 AM4/28/06
to Mike Connor, dev-pl...@lists.mozilla.org
Mike Connor wrote:
> We need to avoid dogmatic principles around openness, and take the highest-value path wherever possible.

"Highest value path" is vague. Highest value in terms of what? Short
term convenience? Community growth? Technical superiority?

We have taken many of these "high value" paths before, many of them have
led us to good places, but not without some pretty significant cost.

-Ben

Ben Goodger

unread,
Apr 28, 2006, 12:56:31 AM4/28/06
to Mike Connor, dev-pl...@lists.mozilla.org
Mike Connor wrote:
> We need to avoid dogmatic principles around openness, and take the highest-value path wherever possible.

"Highest value path" is vague. Highest value in terms of what? Short

Boris Zbarsky

unread,
May 1, 2006, 2:52:00 AM5/1/06
to
Brett Wilson wrote:
> Maybe, but I doubt we'll get around to retargeting everything until
> after 2.0a2. I think it's in a pretty good state. It will be much better
> than the 2.0a1 release we already did, and I'm not sure the trunk alpha
> requires better quality than the last one.

Quite frankly I don't buy that, but that's because I actually want people to
test the trunk alpha. ;)

It's comments like http://mozillazine.org/talkback.html?article=8283#19 that
worry me. Maybe all the people testing trunk who're ok with things are just not
feeling a need to say anything, and maybe the issues are largely resolved at
this point. I'm not using Places-enabled builds for my daily browsing (and not
likely to be in the near future unless Places comes to Seamonkey), so it's a
little difficult for me to judge how actual usability of the builds is affected.

So who here _does_ use a Places build day-in and day-out? Are there any bugs in
it that would prevent widespread testing of Gecko 1.9a? Basically, anything
that would prevent a not-too-clueless user from using the browser for at least a
month?

If there are such bugs, please nominate them to block Gecko 1.9a1.

Thanks,
-Boris

Robert O'Callahan

unread,
May 1, 2006, 3:52:45 AM5/1/06
to
Boris Zbarsky wrote:
> So who here _does_ use a Places build day-in and day-out?

Me.

> Are there any bugs in it that would prevent widespread testing of Gecko 1.9a?
> Basically, anything that would prevent a not-too-clueless user from
> using the browser for at least a month?

I don't think so. Bookmarks work. What else do you need?

Rob

Chris Hofmann

unread,
May 1, 2006, 10:28:38 AM5/1/06
to Robert O'Callahan, dev-pl...@lists.mozilla.org
I've been using the daily trunk builds exclusively for the last couple
of weeks, and many of the problems I saw early seem to have been cleaned
up. Anyone switching back and forth between trunk and 1.5/2.0 branch
builds? We should figure out what shape migration back to non-places
builds will look like by 1.9a1. That might be the key to deciding.

chris h,

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