Places/StatusMeetings/2006-10-05

From MozillaWiki
Jump to navigation Jump to search

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.