Skip to content
This repository has been archived by the owner on Feb 12, 2020. It is now read-only.

Latest commit

 

History

History
86 lines (70 loc) · 5.16 KB

DEVELOPING.md

File metadata and controls

86 lines (70 loc) · 5.16 KB
Raw

PyCCD Development Process

Roles

  • Developer
  • Technical Reviewers
  • Science Reviewers
  • Change Review Board - in addition to the decisions makers, we recommend the board include one or more of the following advisors:
  • An advocate for developers
  • A library maintainer / release manager representative
  • An operations representative
  • Software Library Maintainers
  • Operations

Workflow

  1. A Developer gets a new idea for a feature
  2. The Developer forks the software repository
  3. The Developer creates a feature branch from the branch named develop
  4. For each new feature, a separate branch is created from the develop branch of the software repository
  5. In other words, each branch has only one feature; if more features evolve from the branch, those need to be put into separate branches
  6. A feature is defined as an indivisible unit of functionality for the given software library
  7. Upon completion of the feature, the Developer submits the branch to Technical Reviewers using the Github "Pull Request" capability
  8. The Developer addresses all technical feedback from peers, but does not merge
  9. The Developer submits feature descriptions and any science changes (e.g., an algorithm update) to Science Reviewers
  10. The Developer addresses all science feedback from peers, but does not merge
  11. The Developer submits the feature to the Change Review Board
  12. The Developer addresses feedback from the Change Review Board
  13. Upon completion of feedback, the Change Review Board will either approve or deny the request to include the feature in a coming release
  14. If the Change Review Board approves a feature for inclusion in a release:
  15. The Change Review Board will determine in which future release the new feature will go -- it may not be the next release
  16. If the feature will go in the next release, the developer will merge only the approved branch to develop or ask the Software Library Maintainer to perform the merge
  17. If the feature will go in a later release, the branch will not be merged until the time of the future release's "release candidate" mode
  18. Features that are not approved are not merged into any branch
  19. The Change Review Board provides a list of features that will constitute a next release
  20. When all the approved features are ready for release, the Software Library Maintainer will create a new release branch named with the version number for that release, at which point it becomes a release candidate
  21. Only features which have been approved by the Change Review Board are allowed in the release branch
  22. During a release, the develop branch will go into "feature freeze" mode: no changes or new features are merged into develop; however, developers may continue their work on their own branches
  23. The only exception to this is when testing shows that a release candidate feature has a bug: a fix is then applied to both the release branch and the develop branch
  24. When a release candidate has been reviewed and tested, the Software Library Maintainer will merge the release branch to the master branch
  25. When the release has been merged to the master branch, the Software Library Maintainer will tag master with the version number of the release
  26. At this point, the feature freeze is over and the develop branch may again have new features (for the next release) merged into it
  27. On the date specified by the Change Review Board, the latest release of the software will be deployed by Operations and thus made available to users of the software

Branching Model for LCMAP-PyCCD

Adopted by LCMAP-PyCCD from Vincent Driessen

lcmap-pyccd git branching model

Code

ccd/__init__.py

Top level interface for exposing functionality. Anything not intended to be called externally should be prefixed with a double underscore. Considered the public interface.

ccd/app.py

Master configuration and service kernel for all other modules. Takes advantage of module level caching on first import. Logging, caching and configuration are set up here and made available to other modules via import.

ccd/cli.py and entry_point scripts

The command line interface is implemented using the click project, which provides decorators for functions that become command line arguments.

Integration with setup.py entry_point is done via click-plugins, which allow cli commands to also be designated as entry point scripts.

See ccd/cli.py, setup.py and the click/click-plugin documentation.

logging

Basic Python logging is used in pyccd and is fully configured in app.py. To use logging in any module:

from ccd import app

logger = app.logging.getLogger(__name__)

logger.info("Info level messages")
logger.debug("Debug code")

Performance TODO

  • optimize data structures (numpy)
  • use pypy
  • employ @lrucache