wiki:2017-09-21

Version 1 (modified by Conrad Huang, 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

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
  • Need to investigate
    • Replace ctypes in atomic with Cython
  • Make ChimeraX tickets viewable publicly
    • Private tickets need to start private
    • Alternative, 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 changes
  • Elaine will add "no private data" to contacts.html
  • Eric 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.