Places/StatusMeetings/2006-10-05

Places meeting: 2006-10-05 4pm PST ==== Places meeting: 2006-10-05 4pm PST

<sspitzer> ok, so looking at http://wiki.mozilla.org/Places:Task_List <sspitzer> should we just run down that list, assign some names, and figure out what me might be missing? <sspitzer> I'm sure we will think of lots more as soon as we start doing more work. <dietrich> sure, sounds fine <sspitzer> ok, starting from the top: <sspitzer> for: will be posting to and discussing places in ff3 on mozilla.dev.apps.firefox <sspitzer> I'd like to clean up and repost what I sent to brettw (hi brett, if you are there!) and the google guys and send to the newsgroup <sspitzer> any objection? <dietrich> nope <brettw> hi <sspitzer> sort of "we're here, where in #places and m.d.a.f" <dietrich> howdy brettw <sspitzer> for the next two items, I'll list all three of our names <sspitzer> will be posting to and discussing places... <sspitzer> developers hanging out in #places <sspitzer> for "* fix trunk regressions caused by disabling places" <sspitzer> I haven't seen lots of regressions, so I'll slap my name down there. ok? <dietrich> ok. we should put something in status whiteboard for those <dietrich> non-places-regression or something <sspitzer> good idea. I'll add that info to this task wiki <sspitzer> for review patch from Myk...and finish backporting non-places changes to trunk , I've got a patch started (waiting review) for one such backport. in addition to reviewing myk's patch, I'd like to go through the tree and look at all MOZ_PLACES ifdef and see what might need some love. <sspitzer> his patch only covers the bookmarks code, and not the whole tree. <dietrich> i can help w/ that also <dietrich> what's the bug# for you patch? <sspitzer> cool, I'll list us both for that. <dietrich> s/you/your <sspitzer> I'll start a new bug with the list of places we need to review to be sure that nothing fell through the crack. I'll do that after our meeting and cc you. <sspitzer> or I may add my patch / info to myks bug <dietrich> k <sspitzer> https://bugzilla.mozilla.org/show_bug.cgi?id=353571 <dietrich> ah, ok, i thought your patch was in a diff bug, was why i asked <sspitzer> I think his patch only covered mozilla/browser/components/bookmarks/ <sspitzer> no, not in a bug yet. <sspitzer> the only patch I have is the one in https://bugzilla.mozilla.org/show_bug.cgi?id=342930 <dietrich> right. i'll review that RSN :) <sspitzer> (no rush, it is not critical) <sspitzer> on to the list... <sspitzer> are microsummaries broken? <sspitzer> no, they are not <sspitzer> dao reported an issue <dietrich> yeah saw that <sspitzer> but it was just pilot error <sspitzer> removing it... <dietrich> cool <sspitzer> per brettw's suggestion, start by implementing the Firefox 2.0 "History" UI on top of Places backend <sspitzer> I'll keep that, if you are cool with that. <dietrich> sure, and if that creeps, please break it out into different bugs, and i can jump in <sspitzer> I'll do that. I'll update you on monday letting you know where I am. (been sidetracked with a software update back port for 1.5.0.x!) <dietrich><sspitzer>: so <dietrich> actually, before any work starts on that, we should break it out into bugs <dietrich> and maybe put swags on it <dietrich> so we can figure out just how much of a job it is <sspitzer> ok, I'll start by logging a meta bug and then bugs for each piece that we can swag. <dietrich> and same for bookmarks (once we figure out where we're going it) <dietrich> awesome <dietrich> i think doing that from the beginning will help us track, and report progress <sspitzer> I agree. <dietrich> which will help out when we explain our plan to mconnor :) <sspitzer> good point. <sspitzer> I've got: <sspitzer> * [dietrich sspitzer] per brettw's suggestion, start by implementing the Firefox 2.0 "History" UI on top of Places backend. Start by logging a meta bug and then log bugs for each part, add swag. <sspitzer> I'll log the bugs today. <dietrich> cool, i'll keep refreshing the wiki <dietrich> or are you doing a big batch edit? <sspitzer> refresh <sspitzer> I just saved <dietrich> k <dietrich> so, the next item is the bookmarks ui <sspitzer> for the bookmarks UI work, I think that all depends on what we do. for starters, we want to keep the existing UI and service <sspitzer> what do you think about MOZ_PLACES_HISTORY and MOZ_PLACES_BOOKMARKS <sspitzer> using them, I mean. <dietrich> are u talking about the schemas? <sspitzer> at the start, while we work on the history ui, we want to keep bookmarks alone. <dietrich> exactly <sspitzer> so when I build with --enable-places <brettw> I wouldn't think you'd need to change the backend <sspitzer> I really just mean MOZ_PLACES_HISTORY for now. But I'd like to keep all the MOZ_PLACES in the tree. <brettw> but you may want those flags for the UI <sspitzer> brettw: I was going to leave the backend alone for this first step. <sspitzer> how about for the bookmark items, we don't list an owner (yet) but we do put a name by figuring out the hard part: "the plan for bookmarks for fx 3" <dietrich><sspitzer>: to clarify, you intend that MOZ_PLACES_HISTORY would use places history backend, but the old skool UI, and bookmarks untouched <dietrich> ? <dietrich><sspitzer>: yeah, i can jump on the bookmarks plan <sspitzer> how about this: <sspitzer> when you do --enable-places, it means (at the start), MOZ_PLACES_HISTORY, and the usages that are bookmarks-on-top-of-places, we make it MOZ_PLACES_BOOKMARKS <sspitzer> which won't be defined <sspitzer> thereby giving us what we want (to start) <sspitzer> this is for the stuff in the UI <sspitzer> so the MOZ_PLACES that disables the old bookmarks service will now be MOZ_PLACES_BOOKMARKS <sspitzer> dietrch: I have you by the bookmarks plan <dietrich> ok <sspitzer> for the bookmark ui issues, I will put [blocked by dietrich] <dietrich> cool <sspitzer> on to perf / testing <sspitzer> can I give v_thunder the first one? <dietrich> sure <sspitzer> fix the Tp test <dietrich> also, <dietrich> add "history unit tests" <dietrich> and change mine to "bookmarks unit tests" <sspitzer> got it <dietrich> those should be separate test suites <sspitzer> I gave dmills: <sspitzer> get some performance benchmarks with various history sizes (places vs non-places) <sspitzer> also <sspitzer> I'll take history unit tests. <dietrich> k <sspitzer> unless you've started that <dietrich> nope <sspitzer> (or have you been doing bookmarks with davel?) <dietrich> i just did the bookmarks ones, and had davel review <sspitzer> excellent <dietrich> he helped figure out how to get it to work w/ the build infra <sspitzer> on top of the places api, or the existing 2.0 bookmarks api? <dietrich> so you can do a global "make check" <sspitzer> very cool. <sspitzer> on to " <sspitzer> Synchronization / Remote Bookmarks" <dietrich> the ones i did were on top of places api <dietrich> so, this is where there's overlap w/ the data model changes <sspitzer> right <dietrich> i think a P1 is to give unique identifiers to each object (bookmark, folder, sep, etc) <dietrich> i think "named separators" is kinda weird <dietrich> i'd rather have an extensibility mechanism for bookmarks <sspitzer> but as long as there is a guid for a separators, sync (of seps) should work. <dietrich> right <sspitzer> is the named thing just something fx 2 had, that is no longer in places, and that broke foxmarks? <dietrich> i think it's that seps can have labels, and they sometimes show up in the UI <dietrich> and foxmarks may have been using them for identification <sspitzer> I think we'd want to support that, if the current places back end does not. <sspitzer> for "reference implementation of sync client (P2)" <sspitzer> I'm not sure about that one. <dietrich> do you mean support the 'named' part? or just unique identifiers? <sspitzer> I mean: seps should get guids, and if the could have labels in fx2, but can't in the current backend in places, I think we need to add that. <sspitzer> so that nothing that gets lost when importing up from fx2 <dietrich><sspitzer>: ok, lets leave it on there, and i'll address it w/ the data model changes <sspitzer> ok. I've got yor name by lots of hard problems: <sspitzer> all the ones in Sync / remote <dietrich> haha rad <sspitzer> and same with API / Data Model / Arch, but I'm sure dmills and I will get in on the action. <sspitzer> I'm not sure what to do Tags and Livemarks yet. <dietrich> we can discuss that more at the summit <sspitzer> another time for the top of the list: schedule meetings for the summit <dietrich> yes <dietrich> i think they're going to do the open sessions again <dietrich> we should have a places session <dietrich> and possibly another breakout session for us to talk tasks, status, whatever arch issues are still open <sspitzer> sounds good. <dietrich> is that it for the list? <sspitzer> yes. here's the overall picture, I think: <sspitzer> at the start, you have lots of hard API / data model problems and decisions and I am going to be doing some history UI stuff, and dmills (who also has some non places work on his plate) will be starting on some perf / tinderbox related stuff. <sspitzer> does the task list sort of reflect that? <dietrich> yeah <sspitzer> are you cool with that, for a starting point? everything can change, of course! <dietrich> yes, that's fine to get us moving <dietrich> i'll post the data model evaluation stuff so we can get public comment on it <sspitzer> cool, and I'll go log the history UI meta bug and the dependent bugs (so we can SWAG / divide it up) <dietrich> k <sspitzer> any objection to me posting this chat log (or a link to it) into the newsgroup (m.d.a.firefox) after I post the "kickoff" post? <dietrich> sure, or just post it to the wiki as meeting notes, and point people to the wiki in your post <dietrich> we might want to set up weekly irc meetings like this, and then just post the log to the wiki each week <sspitzer> good idea. how about mentioning in my kick off post that we will be meeting in #places at 4pm thursdays PST? <sspitzer> (or is that not a good time for you?) <dietrich> sounds good :) <dietrich> wfm <sspitzer> (worldwide, is that an ok time?) <sspitzer> (east coast?) <dietrich> uh, yeah we might want to do it in the AM, if we think east coasters and euros want to be there <dietrich> well, but this is more team meeting than a progress report <dietrich> let's just keep it at 4 for now <dietrich> if people want a different time, they'll ask :) <sspitzer> ok, will do. I'll say our team meeting is 4pm thur PST.