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.
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. ;)
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.
> 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 /
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
-- / mike beltzner / user experience lead / mozilla corporation /
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.)
>> 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.
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.
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.
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.
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.
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 ...
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).
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.
> 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.
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...
>> 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.
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.
nrtho...@gmail.com wrote: > 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 ?
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.
>> 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...
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.
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.
>> 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.
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.
