You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we need a proper way to solve issues like LSSTDESC/desc-help#53 by providing the collaboration with an efficient way to evaluate adequacy of a dev package for integration into the DESC ecosystem, and a more organized way to build the path to acceptance.
One easy enough possibility is to build on the actions of this repo to propose a sequence to developers : branch desc-python, modify its actions so as to trigger CI on the new package, and push with CI triggered on push. We can envision different level of CI depending on push to branch, pull request to bleed or to master, etc...
This would not solve for all the things that need to be properly checked by developers, and certainly not the algorithmic correctness, but at least: 1/ this will provide a wiew into proper install at the time of the pus and pull requests, 2/ we can check dependency consistency, like tagged versions of other packages 3/ we can triage the pull request and iterate with much better clarity on purpose/scope/unit testing, in some cases the tests dir will be available and pytest can be triggered in the CI, and we can propose a differential level of scrutiny between bleed dev and the final acceptance in the production version.
comments and thoughts most welcome
The text was updated successfully, but these errors were encountered:
we need a proper way to solve issues like LSSTDESC/desc-help#53 by providing the collaboration with an efficient way to evaluate adequacy of a dev package for integration into the DESC ecosystem, and a more organized way to build the path to acceptance.
One easy enough possibility is to build on the actions of this repo to propose a sequence to developers : branch desc-python, modify its actions so as to trigger CI on the new package, and push with CI triggered on push. We can envision different level of CI depending on push to branch, pull request to bleed or to master, etc...
This would not solve for all the things that need to be properly checked by developers, and certainly not the algorithmic correctness, but at least: 1/ this will provide a wiew into proper install at the time of the pus and pull requests, 2/ we can check dependency consistency, like tagged versions of other packages 3/ we can triage the pull request and iterate with much better clarity on purpose/scope/unit testing, in some cases the tests dir will be available and pytest can be triggered in the CI, and we can propose a differential level of scrutiny between bleed dev and the final acceptance in the production version.
comments and thoughts most welcome
The text was updated successfully, but these errors were encountered: