Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/TM/Committer Phone Meeting 17-Oct-2007"
(→Current Work) |
|||
| Line 28: | Line 28: | ||
=== Current Work === | === Current Work === | ||
* '''Skype Call Quality''' | * '''Skype Call Quality''' | ||
| + | ** Excellent for everyone today (7 participants) | ||
* '''Code and Branching''' | * '''Code and Branching''' | ||
| + | ** continue working on HEAD; Martin can merge fixes to maintenance branch | ||
| + | ** If a fix is a candidate for M-builds, please attach the patch on bugzilla and let Martin know | ||
| + | ** Releasing into the M-builds is not painful for Martin but may be painful if not done before; Instructions are on [https://bugs.eclipse.org/bugs/show_bug.cgi?id=205297#c11 Bug 205297 comment 11] | ||
| + | ** N-builds good for now, no need for I-builds | ||
* Committer Calls frequency | * Committer Calls frequency | ||
| + | ** keep 2 weeks | ||
* '''Planning''' - '''AI Martin''' to write up what we discussed in Toronto | * '''Planning''' - '''AI Martin''' to write up what we discussed in Toronto | ||
| + | ** Project Plan tbd; Xuan won't send notes because stuff is on the "Future Planning" page anyways. | ||
* Bug Fixing - '''Remember our 2-fix-per-week / 3 unittests-per-milestone plan''' | * Bug Fixing - '''Remember our 2-fix-per-week / 3 unittests-per-milestone plan''' | ||
| + | ** DaveD is positive to hit the fix rate, hopefully more | ||
| + | ** Deadline today at IBM for non-opensource stuff, should be better afterwards | ||
| + | ** DaveM will merge some dstore specific stuff | ||
| + | ** Migration going forward without too much help from core openRSE team | ||
* '''Reminder:''' [http://wiki.eclipse.org/BugDay/October_2007 BugDay] next Friday (October 26) | * '''Reminder:''' [http://wiki.eclipse.org/BugDay/October_2007 BugDay] next Friday (October 26) | ||
* '''DaveD:''' - vacation - {{Bug|202630}} new meaning of "default private system profile"? | * '''DaveD:''' - vacation - {{Bug|202630}} new meaning of "default private system profile"? | ||
| + | ** taken some time to check Terminal on the Mac | ||
| + | ** compile error in HEAD! Cannot compile on the Mac! protected VirtualCanvas.getBackgroundColor() does not override private Control.getBackgroundColor() | ||
* '''DaveM:''' - {{Bug|187739}} exists() method in the SystemViewElementAdapter | * '''DaveM:''' - {{Bug|187739}} exists() method in the SystemViewElementAdapter | ||
* '''Kevin:''' - | * '''Kevin:''' - | ||
| − | * '''Xuan:''' - | + | * '''Xuan:''' - any stuff involving NLS need to be finished by M6 (end of march); docs freeze is June 27 |
| − | * '''Javier:''' - will look at {{Bug|199773}} FTP upload as binary | + | ** Platform re-releasing 3.3.1 -- Martin: If Europa is updated, TM will also have updates there from the M-branch. |
| + | * '''Javier:''' - n/a today (will look at {{Bug|199773}} FTP upload as binary) | ||
* '''Martin:''' | * '''Martin:''' | ||
| + | ** Mostly been working on Terminal / M-builds | ||
** {{Bug|202416}} '''Question for DaveD:''' NPE when loading profile: made it more robust, but how could it come that RSE profile data is wiped with zeros? What happens when an IOException occurs while saving a profile, can it become corrupted or is there a safeguard? | ** {{Bug|202416}} '''Question for DaveD:''' NPE when loading profile: made it more robust, but how could it come that RSE profile data is wiped with zeros? What happens when an IOException occurs while saving a profile, can it become corrupted or is there a safeguard? | ||
| − | * '''Uwe:''' - | + | *** DaveD: Never seen an exception - exceptions are logged but profile save fails silently; there is no recovery |
| + | *** Martin: Potentially inform the user about exceptions during save; workspace on NFS drive is not recommended; perhaps fall back to different file name | ||
| + | *** Profile save is below UI layer - would need new API allow catching exceptions! | ||
| + | *** --> Filed new {{Bug|206640}} - could perhaps register with the Manager | ||
| + | ** Was at ESE2007 - good attendance at TM talk; | ||
| + | *** SAP ([http://www.eclipsecon.org/summiteurope2007/index.php?page=detail/&id=65 link to slides]) making [https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Java/Java+Memory+Analysis Memory Analyzer] available for free now, a great fast tool for analyzing heap dumps | ||
| + | *** Xuan was not sure how to send a "stop" signal to a remote server process (Martin: do ps, then kill -QUIT process_id) | ||
| + | * '''Uwe:''' - working on commercial product | ||
* '''Rupen:''' - {{Bug|204307}} Should listFolders(IRemoteFile parent, String fileNameFilter, IProgressMonitor monitor) passing a null FileNameFilter parameter, be dealt with in the same way as listFiles and listFoldersAndFiles. This would require that all folders are returned by assigning a '*' to the fileNameFilter as oppose to leaving it null which is causing a NPE whenever listFolders(IRemoteFile parent, IProgressMonitor monitor) is called. This will require a javadoc change as well. | * '''Rupen:''' - {{Bug|204307}} Should listFolders(IRemoteFile parent, String fileNameFilter, IProgressMonitor monitor) passing a null FileNameFilter parameter, be dealt with in the same way as listFiles and listFoldersAndFiles. This would require that all folders are returned by assigning a '*' to the fileNameFilter as oppose to leaving it null which is causing a NPE whenever listFolders(IRemoteFile parent, IProgressMonitor monitor) is called. This will require a javadoc change as well. | ||
| − | * '''Michael:''' - | + | ** DaveM: should be treated the same, accepting patch |
| + | * '''Michael:''' - n/a | ||
* '''Questions''' | * '''Questions''' | ||
| Line 49: | Line 72: | ||
== Vacation, Away == | == Vacation, Away == | ||
| − | |||
| − | |||
== Action Items == | == Action Items == | ||
Revision as of 11:55, 17 October 2007
| Meeting Title: | TM Committer Phone Meeting |
| Date & Time: | Wednesday Oct 17, 2007 at 1500 UTC / 1100 Eastern |
| Dial-in: | Martin to call everybody by Skype |
Backup dial-in: International +44 (0)1452 567588 / Freephone +1 (866) 6161738 / UK 08712460713 / Passcode: 0587322148 #
MartinO to start conference call - please dial in using the numbers above.
Please be available for Skype Chat in parallel to the call. MartinO will start Skype chat just prior to call.
Skype dial-in: martin.oberhuber, ddykstal (or david_dykstal), david-k-mcknight, kushal.munir, kevin.j.doyle, xuan.chen886, rupen.mardirossian, javier.montalvoorus, tedatteddotnet, michael_scharf, and uwe.stieber.
Attendees
- IBM - Xuan Chen, Dave McKnight, Kevin Doyle, Dave Dykstal, Rupen Mardirossian
- Wind River - Martin Oberhuber, Uwe Stieber, Michael Scharf
- Symbian - Javier Montalvo Orus
This is an Open call, so anyone else can join (though we expect the talk to be interesting for committers only).
Agenda
- Last meeting: DSDP/TM/Committer Phone Meeting 3-Oct-2007
Current Work
- Skype Call Quality
- Excellent for everyone today (7 participants)
- Code and Branching
- continue working on HEAD; Martin can merge fixes to maintenance branch
- If a fix is a candidate for M-builds, please attach the patch on bugzilla and let Martin know
- Releasing into the M-builds is not painful for Martin but may be painful if not done before; Instructions are on Bug 205297 comment 11
- N-builds good for now, no need for I-builds
- Committer Calls frequency
- keep 2 weeks
- Planning - AI Martin to write up what we discussed in Toronto
- Project Plan tbd; Xuan won't send notes because stuff is on the "Future Planning" page anyways.
- Bug Fixing - Remember our 2-fix-per-week / 3 unittests-per-milestone plan
- DaveD is positive to hit the fix rate, hopefully more
- Deadline today at IBM for non-opensource stuff, should be better afterwards
- DaveM will merge some dstore specific stuff
- Migration going forward without too much help from core openRSE team
- Reminder: BugDay next Friday (October 26)
- DaveD: - vacation - bug 202630 new meaning of "default private system profile"?
- taken some time to check Terminal on the Mac
- compile error in HEAD! Cannot compile on the Mac! protected VirtualCanvas.getBackgroundColor() does not override private Control.getBackgroundColor()
- DaveM: - bug 187739 exists() method in the SystemViewElementAdapter
- Kevin: -
- Xuan: - any stuff involving NLS need to be finished by M6 (end of march); docs freeze is June 27
- Platform re-releasing 3.3.1 -- Martin: If Europa is updated, TM will also have updates there from the M-branch.
- Javier: - n/a today (will look at bug 199773 FTP upload as binary)
- Martin:
- Mostly been working on Terminal / M-builds
- bug 202416 Question for DaveD: NPE when loading profile: made it more robust, but how could it come that RSE profile data is wiped with zeros? What happens when an IOException occurs while saving a profile, can it become corrupted or is there a safeguard?
- DaveD: Never seen an exception - exceptions are logged but profile save fails silently; there is no recovery
- Martin: Potentially inform the user about exceptions during save; workspace on NFS drive is not recommended; perhaps fall back to different file name
- Profile save is below UI layer - would need new API allow catching exceptions!
- --> Filed new bug 206640 - could perhaps register with the Manager
- Was at ESE2007 - good attendance at TM talk;
- SAP (link to slides) making Memory Analyzer available for free now, a great fast tool for analyzing heap dumps
- Xuan was not sure how to send a "stop" signal to a remote server process (Martin: do ps, then kill -QUIT process_id)
- Uwe: - working on commercial product
- Rupen: - bug 204307 Should listFolders(IRemoteFile parent, String fileNameFilter, IProgressMonitor monitor) passing a null FileNameFilter parameter, be dealt with in the same way as listFiles and listFoldersAndFiles. This would require that all folders are returned by assigning a '*' to the fileNameFilter as oppose to leaving it null which is causing a NPE whenever listFolders(IRemoteFile parent, IProgressMonitor monitor) is called. This will require a javadoc change as well.
- DaveM: should be treated the same, accepting patch
- Michael: - n/a
- Questions
- Bugzilla:
Vacation, Away
Action Items
- Last Meeting Action Items
- DaveD: fixes, unit tests
- DaveM: fixes, unit tests
- Xuan: fixes, unit tests
- Kevin: fixes, unit tests
- Martin: Write-up TM 3.0 Plan; Look at PropertyDescriptor issues; unit tests; Releng Fixes, Newsgroup
- Javier: fixes, unit tests
- Michael: Terminal performance improvements