Places and Firefox 2

classic Classic list List threaded Threaded
89 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Places and Firefox 2

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

Re: Places and Firefox 2

Matt Nordhoff
On 04/24/06 01:00, Michael Schroepfer wrote:

> 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.

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

Re: Places and Firefox 2

Matt Nordhoff
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
(aka Peng on IRC & the forums)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Places and Firefox 2

Matt Nordhoff
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.
--
Matt Nordhoff
(aka Peng on IRC & the forums)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Places and Firefox 2

steve.england@gmail.com
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.

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

Re: Places and Firefox 2

Jeff Schiller
[hidden email] 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...;)

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

Re: Places and Firefox 2

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

Re: Places and Firefox 2

Vladimir Vukicevic-2
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.

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

Re: Places and Firefox 2

Benjamin Smedberg
Vladimir Vukicevic wrote:
> 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.

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

Re: Places and Firefox 2

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

Re: Places and Firefox 2

Mike Connor-4
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:
> Vladimir Vukicevic wrote:
>> 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.
>
> 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).
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Places and Firefox 2

Benjamin Smedberg
In reply to this post by Benjamin Smedberg
Mike Connor wrote:

> Benjamin Smedberg wrote:
>> Vladimir Vukicevic wrote:
>>> 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.
>>
>> 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).

> 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?

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

Re: Places and Firefox 2

Jeff Schiller
In reply to this post by Benjamin Smedberg

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"...

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

Re: Places and Firefox 2

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

Re: Places and Firefox 2

Mike Shaver
In reply to this post by Benjamin Smedberg
On 4/24/06, Benjamin Smedberg <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Places and Firefox 2

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

Re: Places and Firefox 2

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

Re: Places and Firefox 2

Mike Shaver
In reply to this post by Jeff Schiller
On 24 Apr 2006 13:49:12 -0700, schiller <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Places and Firefox 2

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

Re: Places and Firefox 2

Mike Connor-4
In reply to this post by Jeff Schiller
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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345