Version 1 (modified by 8 years ago) ( diff ) | ,
---|
Attendees
- Conrad, Elaine, Eric, TomG, Greg, TomF
Agenda
- Review action items from 9/14 meeting
- Vijay's visit
- Beta release discussion
- Next meeting
- Glycosylation depiction
- Who will develop mmCIF writer? ticket
- ChimeraX on Github
- Rotamer library license
Discussion
- Beta release discussion (including 9/18 minutes)
- Why do we need a beta so soon? Why not leave it as alpha?
- we said we would
- demonstrates progress, although alphas do that too
- a beta is a milestone that shows more confidence in the functionality and stability of what we are releasing
- it looks bad not to have a beta given the time spent in development
- would send a message to reviewers of our R01 proposal that we have made significant progress on this project
- What does it mean to release an API?
- Using mechanism to be established, we label functions/attributes/properties/etc as API if we intend to support semantic versioning for them
- Developers can use non-API items but have no guarantees that they will continue to work
- Developers should be able to easily determine whether an item is part of “the API”
- What consists of "the API"? Public methods, even those without Sphinx documentation?
- It is easier to mark items as part of the API than to mark items that are NOT part of the API
- There are methods that should not start with underscore because they are shared among classes internally, but are still not part of “the API”
- Tentative APIs also should not be labeled as part of the API because we may not support forward compatibility
- 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]
- Annotation on non-API items: decorators (does not work with attributes and properties) or doc string markers (e.g., “unsettled”)
- doc strings will work for attributes, optional arguments
- we agree that this is a viable solution but not the one we will use
- will need to go through source code and add everything before beta
- Annotation on API items: decorators/doc strings
- Developers will not see non-API items clearly marked
- Omission of markup less detrimental
- Less effort
- Might leave more markup in the long run (if public API outnumbers non-API items)
- we agree that this is a viable solution and IS THE ONE WE WILL USE
- we will use doc strings rather than decorators because doc strings work for properties.
- attributes will be documented in the class doc string
- Marker string is "Supported API." at the beginning of the doc string
- will need to go through source code and add everything before beta
- Have a utility that identifies non-API items in bundles (may not be practical)
- How much "firming up" API is needed?
- If it’s ready, it’s ready
- If it’s iffy, it’s not
- Will bundles move out from core, e.g., atomic?
- Do it before beta and there is no API change needed later
- Most import’s will need to be changed when package is externalized
- Toolshed images/documentation needs effort
- Order packages based on dependency
- Eric will try to bundle-ize core.ui after preferences
- What are the beta APIs? Toolshed. Atomic. Command…
- The plan is to write a tutorial for a "simple" bundle supporting commands and HTML widget GUI
- beta APIs must support everything in the tutorial
- Release protocol for "core" bundles? (defer for now)
- Is December a realistic target?
- it depends whether the milestone is more important or more functionality is more important
- Why do we need a beta so soon? Why not leave it as alpha?
- Need to investigate
- Replace ctypes in atomic with Cython
- Make ChimeraX tickets viewable publicly
Private tickets need to start privateAlternative, make all tickets public and make UI say "don't send private data"- Make tickets public now and add warning later when needed
- Beta release topics
- Meeting on Monday
- Why do we need a beta so soon? Why not leave it as alpha?
- Is December a realistic target?
- Will bundles move out from core, e.g., atomic?
- What are the beta APIs? Toolshed. Atomic. Command...
- How much "firming up" API is needed?
- What consists of "the API"? Public methods, even those without Sphinx documentation?
- Release protocol for "core" bundles?
Action Items
Greg will make session file format changesElaine will add "no private data" to contacts.htmlEric will add "no private data" to traceback printout in log- Conrad will make tickets publicly readable
- Conrad will continue working on ribbon tickets
- Conrad will investigate implementing the "like" operator
- e.g., to specify polymer in atomspec
Conrad will send mail to RCSB about bad pdb.org certificate
Note:
See TracWiki
for help on using the wiki.