MailNews:HgMeetingNotes

SeaMonkey, Calendar, Thunderbird structure in the new Mercurial World

• Meeting triggered to sort through issues that come up in
  • Original proposal from Kairo http://home.kairo.at/blog/2008-06/a_possible_way_for_hosting_seamonkey_and
  • Subsequent mozilla.dev.planning discussion

• Big reasons a 3-way shared hg repo is interesting
  • tb and calendar want to coordinate closely because increasing overlap
  • tb and seamonkey want to coordinate closely because of shared mailnews/ code

• Key question: granularity of repositories
  • how concerned should we be w.r.t. size of repo?
    • kairo: initial pull times are long
      • dmose: more important to optimize for update times, since that's the common operation
      • ted: hg always pulls more data than CVS
      • ted: benjamin has a way to deal with that http://benjamin.smedbergs.us/blog/2008-06-05/getting-mozilla-central-with-limited-bandwidth/
    • dmose: mozilla-central appears to be about an order of magnitude larger than calendar/ + mailnews/ + mail/ (forgot to count suite/ here, though)
    • ted/dmose: mozilla-central likely to hit and have to deal with/solve any scaling problems long before this repo will see them
    • bsmedberg/ted: putting calendar in a separate repo seems unlikely to be much of a win

• top-level stuff needs to be shared across all projects
  • We've successfully done this coordination in CVS across a much larger number of projects for many years.
  • dmose: given the relatively smaller number of people working on these three projects, the benefits of keeping them aligned seem much greater than the costs. So much so that it seems unlikely that anyone's going to want to get out of sync for quite a while.

addressing some concerns from KaiRo's blog post

• LDAP
  • C SDK: import from stable branch, a la NSPR/NSS
  • XPCOM SDK
    • bsmedberg: probably not in mozilla-central
    • dmose: only known consumer is the ldap-autoconfig code for firefox & suite
      • dmose/ted: shouldn't let that tail wag the dog

• stuff in extensions/
  • lightning/ could just go away
  • webdav/
    • dbo: that dependency should be disappearing very soon

• make-makefile
  • ted: consider keeping sync-ed copy of the our own mozilla buildsystem (somewhat similar to spidermonkey)
    • individual configure for our step, call into mozilla-central configure
    • make check target to ensure stay in sync

misc other logistical questions

• L10n
  • Gecko / Fx story not yet clear; Pike is working on it

• dmose: how much work needs to be done in and around the switch?
  • ted: the work is in making builds work locally, once that's done, making buildbot do builds is should be pretty easy, given that this work has already been done for Firefox/Gecko

• pain point: lack of easily queryable bonsai
  • code being written; pain will diminish in upcoming weeks

• migration: calendar
  • keep in CVS until ready
  • use client.py to pull directly from CVS

• migration: seamonkey
  • what to do until nightlies get set up for hg?
    • get working locally using local hacks
    • get buildbots going
    • have flag day to move over

• how much history to import?
  • bsmedberg: the trunk-cvs-mirror thing was not worth the pain
  • ted has tool for annotations that (in a basic way) span hg and cvs mostly working
    • good chance this will be supported in the next 6 months in one way or another
    • given the above, not worth trying to import history

Next Steps

• dmose & dbo will talk tomorrow (before dbo's vacation)
• kairo to work with ted and others to get 3-way test repo running
• mozilla.dev.builds, #hg or #build channel for discussion