DSDP/TM/Committer Phone Meeting 14-Aug-2007
|Meeting Title:||TM Committer Phone Meeting|
|Date & Time:||Tuesday Aug 14, 2007 at 1500 UTC / 1100 Eastern|
|Dial-in:||asterisk.eclipse.org ID: 8988 Passcode: 12345|
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 fallback dial-in - only if less than 5 participants: martin.oberhuber, ddykstal (or david_dykstal), david-k-mcknight, kushal.munir, kevin.j.doyle, xuan.chen886, javier.montalvoorus, tedatteddotnet, michael_scharf, and uwe.stieber.
- IBM - Xuan Chen, Kevin Doyle
- Symbian - Javier Montalvo Orús
- Wind River - Martin Oberhuber
This is an Open call, so anyone else can join (though we expect the talk to be interesting for committers only).
- Last meeting: DSDP/TM/Committer Phone Meeting 8-Aug-2007
- Asterisk Conferencing
- Totally Failed today -- Martin could login, Xuan and Kevin not - connection very choppy
- Kevin Read-Only Questions
- bug 197855 - when to enable the move / delete actions? - Depends on the File System: since we have no IFileService#canDelete(), we should always enable the action. Worst case is, that an error occurs when actually moving / deleting. That error should then be displayed to the user. But we have to rely on the user knowing what he does.
- Same bug -- NPE's in DecoratorManager after a file has been deleted, because the DSToreHostFile's name is null: DStore uses name==null to indicate deleted files. Therefore, IHostFile#isFile(), exists() etc. all need to return "false" if the name==null. Need to document this in the code.
- bug 168219 - confirmation dialog for delete / move when a file/folder is read-only: always show the dialog. Live with the case that on UNIX, user can press "OK" to delete file, but the action could still fail (because parent is read-only). Should we try "setWritable" before trying to delete it?
- EFS Eclipse LocalFile#delete() does not set writable -- it fails with an exception in case Java cannot do java.io.File.delete()
- We should not make the IFileService too intelligent -- don't try to setWritable in IFileService.delete()
- But the File subsystem, when showing the confirmation dialog, could try to setWritable when the user confirmed deletion
- One problem could be, that when recursively deleting a tree in which some files are read-only, we are not asked for them
- Windows explorer asks for confirmation of read-only files ... can do "Yes for all"
- Don't get a MultiStatus with delete errors
- Another BugDay on August 31st -- TM to take part (was announced on PlanetEclipse)
- Rupen Question
- When shell is being created, the inputLine is disabled -- so it cannot get the focus. Is there a reason for having it disabled in createControl()?
- don't know, try it out
- Xuan Question
- Logging: how to install the handler
- Won't have much time this week, because DaveM is not here
- One P1 for blocking in archive handler - may need to defer, because API does not allow for cancel
- Xuan week off end of August
- DaveD vacation Aug.8 till Aug.20
- DaveM vacation Aug.6 till Aug.21
- Javier vacation Aug.13 till Aug.31
- Last Meeting Action Items
- DaveD: 2.0.1 important fixes, then Doc bugs (Tutorial)
- DaveM: Ask Pete Nicholls about room for F2F meeting in Toronto; bug 196662 refresh on dispatch thread
- Xuan: Unit Tests
- Kevin: 2.0.1 fixes
- Martin: Look at PropertyDescriptor issues; EFS fixes; unit tests; Migration Docs, EFS Fixes, Releng Fixes, Newsgroup
- Javier: 2.0.1 fixes, unit tests
- Michael: Terminal performance improvements