r124 - 21 Jul 2007 - 12:10:12 - KatieCappsParlanteYou are here: OSAF >  Projects Web  >  DevelopmentHome > ServicesWorkingGroup
See the Chandler Desktop team for current progress and activities.

Services Working Group Home Page

The services working group discusses a collection of related projects that support Chandler from inside, including utilities, protocol engines, and semantic storage (content model, as opposed to data model).

People

Schedule

Person 0.5.03 0.5.04 0.5.05
BrianK SSL/TLS, POP initial support I18n framework Store/sync IMAP folders?
Grant Zanshin, integration with Chandler, ETag support (12 days) Timezone spec review, tickets, Timezone implementation CalDAV (7 days), tombstones
Morgen Share filtered collections, logic and GUI Finish 03 tasks; Merge changed shared items, log changes, tickets Sharing termination, share as ICS
Jeffrey Recurrence spec, API and data model importing recurring meetings Exporting recurring meetings
Phillip Schema API, rewrite core packages Schema API finish (clouds), parcel migration, repository related work Stamping?
Heikki Cert store, Add certs, STARTTLS Dynamic adding of certs, ACL + zanshin Finish ACL library
MikeT wxWidgets upgrade, python upgrade, subversion switchover Tinderbox/Bonsai SVN integration, Sharing instrumentation FC4?

Status

May 24 Status

Who Progress Plans Other (OOF, questions)
Jeffrey Checked in some iCalendar tests; deferred some refactoring that would allow better tests. Progress on Recurrence spec Finish recurrence spec and start implementing  
Brian Messaging scheme finalized for i18n spec; working with Andi on pyICU; patches to submit to getText support for Python Final stake in ground on i18n; imminent posting to dev list  
Heikki Mostly IT organization (scrubbing tickets lists) and spec work. M2Crypto work. Found that query notifications don't work across threads -- this was a continuation of the investigation of last week Continue working with Ted on notification problem; investigate workarounds if a fix isn't possible in 0.6 Will be gone on vacation and conferences for 1 month starting next week.
Grant Was on AIDS ride Updating project stuff: Wiki pages, zanshin spec. Creating a test WebDAV server  
Mike Helping IT work; coding on the Bonsai SVN conversion project P1 build bugs, startup unit tests  
Aparna See AparnaKadakia20050614    
Anthony See AnthonyFranco20050614    
Phillip See DevPlatformMtg20050614    
Morgen See DevPlatformMtg20050614    
Lisa iCalendar spec additions Work on Wiki reorg and content update  

Bugzilla status by person (shows only tasks that have been entered in Bugzilla):

Active/0.6 Projects

0.6 Community Goals

  • QA/ testing of email interaction with imap servers

Old/inactive projects

Meeting Notes and old milestone status

Meetings are Tuesdays at 3:00 pm.

Notes for Jun 7

Discussion of changes proposed to unit test framework: run_tests. Impetus was to allow a distinction between unit tests and integration tests -- maybe developers only need to run unit tests constantly, and run integration tests occasionally or leave those to Tinderbox. Mike said that if more of developers are doing run_tests, then that's what Tinderbox needs to be doing too. The hardhat way of doing tests starts a whole new Python session for each test which is why it takes longer. As opposed, run_test catches resource leaks because it uses the same Python session. But the hardhat approach can catch bugs that cancel each other out... In the best of worlds we'd run both.

Discussion of build schedules: OK to delay builds until morning after checkins so Bear doesn't have to stay up really late; also OK if a build is dropped and QA has to test it the following workday rather than stay up late in the night. Candidate builds take only 20 minutes now.

Notes for May 24 See status table

Parcel schema API discussion: The combination of parcel XML plus schema API does make for a complicated situation. We have to make namespaces work for both approaches and load things in the right order. Tests like "test all parcels" load everything, then subsequent tests are confused by all things being loaded already and trying to start parcels previously loaded (the parcel loader sees more stuff there than it originally saw)

Currently there's a "schema.reset()" function that wipes out schema -- this is a stopgap to clean things up between unit tests being run in the same process.

Problems seen in schema API have been related to not thinking about transition period from complete parcel XML. Parcel loader needs to be able to reset schema created through Python and vice versa. The reset stuff was put into repository test case object.

Can you force parcels to load only their own stuff and not rely on other parcels being loaded first? Can you avoid a fragile order dependency? E.g. mail creates a space for placing mail at a later date... a phase for item setting up might have to be separate from starting services (with a possible exception of creation of storage areas)

Notes for May 10 See status table. Other discussions taken to dev list.

Notes for April 12

Discussion of 0.6 schedule

  • Two milestones, each a month long, are planned so far
  • (weekly builds are not milestones)
  • Detailed planning will focus on first milestone to start with (naturally!)

Discussion of role/use of code reviews, rough transcript:

Heikki: believes code reviews should happen before every checkin.
Morgen: asked whether this would be for all checkins, big and small.
Phillip: much much rather see tests than code reviews.
Lisa: process I've used was that the code review time was also a time to verify that unit tests existed and were sane.
Heikki: if you write unit tests first, and nobody reviews them, it's possible for the unit tests themselves to be broken and the code review could find that too. Unit tests could be incomplete, missing edge cases.
Somebody noted that David Surovell made a bunch of checkins on column header then did a code review on all of that -- a successful example of not code-reviewing for every checkin but still getting the project code-reviewed.
Phillip: pair programming is the ultimate in code reviews
Mike: we did a fair bit of pair programming at the end of 0.5
Jeffrey: there must be cultural things that are different for people who are remote
Morgen: How do you schedule people and not burden them with code reviews
Mike: bug-related code reviews aren't a scheduling burden -- that approach works for only small-to-medium sized bug reviews, but they work well for that.
Phillip: Depends on whether the reviewers are a bottle-neck or not.
Lisa: We can spread the code reviews around, although sometimes one person is required.
Grant: Explaining what you're doing -- the interactive part of the code review -- is actually very very helpful.
Lisa: So do we continue doing what we did in 0.5? Do code reviews as the judgement of the developer decides?
Heikki: Mandatory code reviews in end-game, judgement call until then?
Mike: When we get to the point of mandatory code reviews in the end-game, we should require people to attach patches to bugs and use that process for code reviews. Particularly the apps bugs.
Morgen: Using a combination of Skype and SubEthaEdit? was nice for code reviews.

Summary: The services team will continue encouraging frequent code reviews in 0.6 and using judgement to determine when not to.

Notes for Mar 29

Status

  • Brian: adding STARTTLS support, including a GUI flag which we probably won't keep in the long term -- just a way to connect for now
  • Brian: Better capturing of M2Crypto errors with certs; automated adding of certs
  • Brian: at Unicode conf next week
  • Jeffrey: communities conference this week
  • Jeffrey: Recurrence rules proposal. Next steps involve talking to Alec about how RFC2445 works & it's reasonably elegant
  • Bear: Doing the release, picking up new splash screen
  • Bear: Plans to clean tinderbox scripts shortly
  • Bear: Planned move to SVN
  • Phillip: Working on repos performance
  • Phillip Proposal in the works for replacing parcel XML with Python definitions for parcel kinds
  • Phillip: Plans to talk to Ted and design team about collection requirements
  • Phillip: how Spike might do i18n; how a parcel might define new translations for a different parcel, so that different parties could contribute parcels and parcel translations
  • Morgen: Wrapped up 0.5 bugs
  • Morgen: Beefed up Zaobao and did a Web-based RSS reader from it
  • Morgen: Tweaking Sharing
  • Morgen: IMAP account setup work with Brian
  • Grant: lots of WebDAV, CalDAV and tickets reading
  • Grant: Moving sharing code to zanshin
    • Phillip noted that python has "mockets" to allow testing of network code without a network
  • Aparna: Verifying remaining 70 out of 170 bugs

Discussion on Spike

  • Definite interest on Brian and Jeffrey's part on using Spike's simpler representations in the long run
  • how long it might take to integrate Spike: fast or slow approaches

Discussion on 0.6 priorities

  • How our priorities changed
    • Polish rather than throw features at the wall
    • Freebusy viewing: costly UI, costly protocol interactions (user lookup)
    • Avoid problems of user lookup and authenticating by using tickets
  • Stickie planning continues

Discussion on recurrence

  • ICU - some pushback?
  • Every instance of a recurrence rule has a recurrence ID, so it's possible to relate notes to individual instances.
  • We can make "exceptions" to the recurrence rule even when there aren't exactly exceptions to the rule (i.e. same time, place and attendees) in order to associate notes
  • Note that Jeffrey's proposal means there will be both virtual and non-virtual instances of events. Which ones show up? How do repository notifications work to tell CPIA what to display in the case of virtual instances?
  • It would be ideal for the design of recurrences not to have to change the way CPIA works or to make CPIA have any knowledge of recurrences in summary or calendar views.
  • Jeffrey and Phillip will get together later to see what repository or data model support must be done to make recurrences work

Discussion on ICU

  • Need to see if Nick's ICU work can be released... currently not open source
  • Phillip recommends using python dateTime stuff to wrap ICU
  • can we use ICU's data files and not the code...
  • can we contribute to that effort to ensure there's one library and not several

Discussion on Twisted

  • Lots of interest and goodwill from PyCon, should build on that
  • Still need high-level, highly usable APIs -- but if necessary we can wrap low-level APIs

Status from Mar 1

  • BrianK?: Finished own bugs, starting on fixing others' bugs
  • Mike: Has 4 bugs in 0.5 product (excluding Hardhat, tinderbox); 2 possible blockers
  • Jeffrey: Has 2 bugs to investigate
  • Grant: Has ~10 parcel bugs to investigate
  • Morgen: TBD
  • Phillip: Spike progress

Notes for Tuesday, Feb 22

  • Very difficult to pick up other peoples' bugs to help fix
    • not many bugs marked 'helpus'
    • APIs confusing and undocumented
  • Bear's bugs
    • Difficult to work through remotely, ssh'ing into build machines
    • Chris needs to ship Bear a Visual C software package
  • Grant's bugs
    • Straightforward bugs almost complete
    • Ambiguous bugs being chipped away at (e.g. parcel loading performance)
    • Hard but obscure bugs on back burner
    • Minor feature requests --> will be punted
  • QA/build plans for next week
    • Code freeze on tuesday -- only blocker bug fixes accepted after
    • QA IRC topic on Wednesday
    • Planning to close tree early on Tues to check build testability
  • Spike review and discussion
    • Now that people are finishing up bugs we'll start to consult with various experts...

Previous months' meeting notes and milestone history

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r124 < r123 < r122 < r121 < r120 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.