Places/StatusMeetings/2006-10-05

index | next week »

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.