Places/StatusMeetings/2006-10-05: Difference between revisions

<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 [http://groups.google.com/group/mozilla.dev.apps.firefox 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.