| | 1 | = Attendees = |
| | 2 | |
| | 3 | * Conrad, Elaine, Eric, TomG, Greg, TomF |
| | 4 | |
| | 5 | = Agenda = |
| | 6 | * Review action items from 9/14 meeting |
| | 7 | * Vijay's visit |
| | 8 | * Beta release discussion |
| | 9 | * Next meeting |
| | 10 | - [http://plato.cgl.ucsf.edu/pipermail/chimera-users/2017-August/013830.html Glycosylation depiction] |
| | 11 | - Who will develop mmCIF writer? [https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/752#comment:3 ticket] |
| | 12 | - ChimeraX on Github |
| | 13 | - Rotamer library license |
| | 14 | |
| | 15 | = Discussion = |
| | 16 | * Beta release discussion (including 9/18 minutes) |
| | 17 | - Why do we need a beta so soon? Why not leave it as alpha? |
| | 18 | - we said we would |
| | 19 | - demonstrates progress, although alphas do that too |
| | 20 | - a beta is a milestone that shows more confidence in the functionality and stability of what we are releasing |
| | 21 | - it looks bad not to have a beta given the time spent in development |
| | 22 | - would send a message to reviewers of our R01 proposal that we have made significant progress on this project |
| | 23 | - What does it mean to release an API? |
| | 24 | - Using mechanism to be established, we label functions/attributes/properties/etc as API if we intend to support semantic versioning for them |
| | 25 | - Developers can use non-API items but have no guarantees that they will continue to work |
| | 26 | - Developers should be able to easily determine whether an item is part of “the API” |
| | 27 | - What consists of "the API"? Public methods, even those without Sphinx documentation? |
| | 28 | - It is easier to mark items as part of the API than to mark items that are NOT part of the API |
| | 29 | - There are methods that should not start with underscore because they are shared among classes internally, but are still not part of “the API” |
| | 30 | - Tentative APIs also should not be labeled as part of the API because we may not support forward compatibility |
| | 31 | - We can use naming conventions (which developers may not know about, might be painful for internal development) [Answer: No, none that could be agreed on] |
| | 32 | - Annotation on non-API items: decorators (does not work with attributes and properties) or doc string markers (e.g., “unsettled”) |
| | 33 | - doc strings will work for attributes, optional arguments |
| | 34 | - we agree that this is a viable solution but not the one we will use |
| | 35 | - will need to go through source code and add everything before beta |
| | 36 | - Annotation on API items: decorators/doc strings |
| | 37 | - Developers will not see non-API items clearly marked |
| | 38 | - Omission of markup less detrimental |
| | 39 | - Less effort |
| | 40 | - Might leave more markup in the long run (if public API outnumbers non-API items) |
| | 41 | - we agree that this is a viable solution and **IS THE ONE WE WILL USE** |
| | 42 | - we will use doc strings rather than decorators because doc strings work for properties. |
| | 43 | - attributes will be documented in the class doc string |
| | 44 | - Marker string is "Supported API." at the beginning of the doc string |
| | 45 | - will need to go through source code and add everything before beta |
| | 46 | - Have a utility that identifies non-API items in bundles (may not be practical) |
| | 47 | - How much "firming up" API is needed? |
| | 48 | - If it’s ready, it’s ready |
| | 49 | - If it’s iffy, it’s not |
| | 50 | - Will bundles move out from core, e.g., atomic? |
| | 51 | - Do it before beta and there is no API change needed later |
| | 52 | - Most import’s will need to be changed when package is externalized |
| | 53 | - Toolshed images/documentation needs effort |
| | 54 | - Order packages based on dependency |
| | 55 | - Eric will try to bundle-ize core.ui after preferences |
| | 56 | - What are the beta APIs? Toolshed. Atomic. Command… |
| | 57 | - The plan is to write a tutorial for a "simple" bundle supporting commands and HTML widget GUI |
| | 58 | - beta APIs must support everything in the tutorial |
| | 59 | - Release protocol for "core" bundles? (defer for now) |
| | 60 | - Is December a realistic target? |
| | 61 | - it depends whether the milestone is more important or more functionality is more important |
| | 62 | |
| | 63 | * Need to investigate |
| | 64 | - Replace ctypes in atomic with Cython |
| | 65 | * Make ChimeraX tickets viewable publicly |
| | 66 | - ~~Private tickets need to start private |
| | 67 | - ~~Alternative, make all tickets public and make UI say "don't send private data" |
| | 68 | - Make tickets public now and add warning later when needed |
| | 69 | * Beta release topics |
| | 70 | - Meeting on Monday |
| | 71 | - Why do we need a beta so soon? Why not leave it as alpha? |
| | 72 | - Is December a realistic target? |
| | 73 | - Will bundles move out from core, e.g., atomic? |
| | 74 | - What are the beta APIs? Toolshed. Atomic. Command... |
| | 75 | - How much "firming up" API is needed? |
| | 76 | - What consists of "the API"? Public methods, even those without Sphinx documentation? |
| | 77 | - Release protocol for "core" bundles? |
| | 78 | |
| | 79 | = Action Items = |
| | 80 | * ~~Greg will make session file format changes |
| | 81 | * ~~Elaine will add "no private data" to contacts.html |
| | 82 | * ~~Eric will add "no private data" to traceback printout in log |
| | 83 | * Conrad will make tickets publicly readable |
| | 84 | * Conrad will continue working on ribbon tickets |
| | 85 | * Conrad will investigate implementing the "like" operator |
| | 86 | - e.g., to specify polymer in atomspec |
| | 87 | * ~~Conrad will send mail to RCSB about bad pdb.org certificate |
![[ChimeraX Issue Tracking System]](/trac/ChimeraX/chrome/site/ChimeraX-icon.svg){kind=icon}
