Build, Release, QA
------------------
*Checkpoint*
Dan tested the checkpoint:
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006875.html

*Alpha4 feature freeze*
Heikki declared feature freeze, Thursday Sept 21. Code changes require
review. Limit changes to bugs/tasks approved by bug council, with
exceptions for build breakages, comments, docs.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006935.html

*Readable Tinderbox*
Responding to John's comment about tinderbox being clear and obvious
about which test failed and why, Dan explained how the functional tests
report errors, gave an example, and asked John if the output was clear
enough or if something different was required.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006880.html

*Policy for Red/Orange Tinderbox*
During a period where Tinderbox had been not-green for an extended
period, Bryan suggested amending the process for better productivity. He
suggested closing the tree, disable broken tests and have high priority
bugs to fix the failures. Bryan pointed out that when the tree has been
broken a while due to weird test failures, people learn to ignore the
rules because they have such a high tax on productivity.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006876.html

Heikki expressed concern at disabling tests as a matter of policy, that
it can lead to checkins that break the disabled tests, which also causes
confusion. He suggested people should be more comfortable backing out a
change that breaks tests.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006878.html

Bryan also noted that waiting for Tinderbox to go green can force people
to build up changes instead of making small checkins. He agreed with the
policy in general, but was suggesting something different for a crisis
(Tinderbox not green for an extended time).
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006881.html

Jeffrey noted that a network outage caused this particular situation. He
expressed frustration at the frequency of test failures that were due to
test framework issues and not new code. He expressed a strong preference
for disabling tests that are flaky and to file bugs to fix the
framework. He noted that there are times where we shouldn't stop
everyone's development momentum because the test framework is letting us
down -- assign a bug and have someone work on it and allow development
to proceed. John, Jeffrey and Katie agreed with Bryan's proposal.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006887.html

Heikki argued that because we have a few intermittent random crashes,
we'd have to disable all of the tests. He would like to see people check
logs for known intermittent failures.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006890.html

Philippe observed the very real frustration, noting that the system is
working against its own objectives if it encourages people to create a
backlog of changes. He noted that we need to fix problems with the
functional test system, including dependencies between tests,
dependencies on the network and 3rd party services, etc. Philippe
proposed a meeting.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006893.html

Dan sent notes from the meeting.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006930.html

*Functional test library change*
Jeffrey changed how SetDisplayName works for collections in
ChandlerTestLib. He made a tradeoff of not going through wx events, with
the benefit of reducing flaky test failures that didn't reveal
underlying problems.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006877.html

*Sharing test slowdown*
Heikki made a change to the performance test for sharing, which caused a
big slowdown. In particular he used App_ns.root.Remove() instead of
collection.delete(recursive=True) to delete a collection from the
sidebar. He asked why the change would have had such a significant answer.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006924.html

*Run do_tests.sh without -O*
Heikki proposed running do_tests without -O (with asserts) when running
release tests alone. When running debug and release tests, run release
tests with -O. John suggested never running with -O.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006945.html

*SuSE*
Claes Larsson ran into troubles running Chandler on SuSE. Philippe
logged Bug 6795 to track it.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006937.html

i18n/l10n
---------
*Localizations in SVN*
Philippe asked how we should store localizations in svn. He proposed
they be stored in the same svn repository as the source they are
localizing.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006898.html

Bear argued that localizations be managed outside the normal dev
process, as they are tied to specific released versions. He suggested
localizations be handled by the distribution process. Placing them in a
different repository allows the localization to be done by non-dev
committers. He suggested docs should be handled the same way.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006900.html

Heikki proposed a structure. He explained that svn has the ability to
link one repository to another.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006912.html

Philippe agreed to Bear and Heikki's proposals. He noted we already have
another "product" besides Chandler -- ChandlerExampmles.
http://wiki.osafoundation.org/bin/view/Projects/LocalizationProject
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006913.html

*Fun with ellipsis*
Philippe explained that text is more localizable if the elipsis
character is used (vs "..."). Unicode now has a unicode character called
"ellipsis expansion". He noted that an ellipsis is not really a
punctuation character; it has semantic meaning and is handled
differently in different languages. Bug 6723 notes usages of "..." to be
fixed.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006938.html

Interoperability
----------------
*Oracle calendar and Chandler*
Viksit asked if Chandler works with Oracle calendar. Jeffrey explained
that we test Chandler against Oracle Calendar at CalConnect events.
Jeffrey noted that it works at a basic level, with some glitches and
omissions. In particular, we don't interoperate with their invitation
system, and you can't share non-event data. Other problems may show up
in different versions.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006916.html


Intern, SoC Projects
--------------------
*MVA and automatic tagging*
Markku and Viksit are reviving the auto-tagging project.
http://wiki.osafoundation.org/bin/view/Projects/AutoTagsProject
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006862.html

Viskit suggested two possible first steps: converting the existing code
to work with alpha4, or get the system up and running without
dependencies on external programs.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006865.html

Markku proposed abandoning the current implementation, explaining that
the one we're shooting for is different enough we should just proceed
with the new implementation. He's not planning on porting Xun's code.
Markku's list of steps included getting tagging implemented in Chandler,
getting real world data set up, implementing MVA operations, etc.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006940.html

Markku asked that the SciPy be included in the distribution. He offered
the alternative of only including NumPy if it was important to optimize
binary size.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006934.html

Dev projects
------------
*Stamping as annotations*
Grant landed the stamping-as-annotation changes. He listed known
problems, including performance regressions. He included a link to notes
about the implementation.
http://svn.osafoundation.org/sandbox/grant/stamping/NOTES.html
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006910.html

Andi noticed that the stamping changes slowed down attribute access. He
moved application.schema's Redirector class to C, bringing the
microbenchmark roughly up to par.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006922.html

*setting focus*
Reid asked about using wx.Window.SetFocus(self.widget) vs
self.widget.SetFocus(), bringing up the ability to override the method.
John recommended creating a widgets handler "self.Bind(wx.EVT_SET_FOCUS,
self.OnSetFocus)".
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006949.html

*reply/forward and stamping*
Brian Kirsch asked whether or not replies and forwards keep their
stampedness. Mimi said that a reply should only be a message, and that a
forward should inherit the stamps of the original item being forwarded.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-September/006954.html

Meetings
--------
Apps meeting:
http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060921
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev

Reply via email to