-
Notifications
You must be signed in to change notification settings - Fork 8
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch '863-make-ophyd-devices-for-rasor' of github.com:Diamond…
…LightSource/dodal into 863-make-ophyd-devices-for-rasor
- Loading branch information
Showing
8 changed files
with
156 additions
and
136 deletions.
There are no files selected for viewing
Validating CODEOWNERS rules …
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
* @DiamondLightSource/bluesky-reviewers |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
# 3. Use CODEOWNERS Github feature to restrict approved reviewers | ||
|
||
## Status | ||
|
||
Accepted | ||
|
||
## Context | ||
|
||
As dodal expands and covers an increasing number of beamlines it is important to maintain quality. So far we have seen good results from following bluesky's own standards: Encouraging high test coverage, readable code (including type annotations, where appropriate) and collective ownership, including via thorough reviews which appropriately balance velocity with technical debt management. We would like to make sure this developer culture is preserved as we expand. | ||
|
||
## Decision | ||
|
||
Have a team of approved reviewers in the DiamondLightSource Github organisation. Every PR into dodal **must** be reviewed by a member of this team before merging (enforced by repo settings and [CODEOWNERS feature](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)). Have a set of [documented criteria](../reviews.md) for becoming part of the team, with the expectation that any team that regularly works on dodal will become members over time. The hope is that a consistent set of standards can be maintained by the approver community. | ||
|
||
## Consequences | ||
|
||
PRs will not be mergable until an approved owner has reviewed them, approved individuals/teams will have to review/support onboarding of new individuals/teams for some time before they are approved for review. | ||
|
||
Once a critical mass of Diamond staff are used to this way of working, this ADR may be obsolete and should be replaced with a more open review system. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,56 @@ | ||
# Approved Reviewers | ||
|
||
Code reviews are an important tool for ensuring both quality and collective responsibility for the codebase. Dodal PRs *must* be reviewed by a member of [the approved review team](https://github.com/orgs/DiamondLightSource/teams/bluesky-reviewers) before they are merged. | ||
|
||
## Review Standards and Practices | ||
|
||
When reviewing you should ensure the code meets the [repository standards](../reference/standards.rst) and [device standards](../reference/device-standards.rst). Approved reviewers will adhere to the following, if they do not, junior reviewers and reviewees should feel empowered to hold them to account. | ||
|
||
### Questions and Comments | ||
|
||
Questions and requests for clarification are encouraged. If you have comments for the reviewer you could add them with the following prefixes to be helpful: | ||
|
||
- **Must**: This will negatively effect functionality if not implemented. The PR will not be merged until the comment is addressed to both the reviewer and developer's satisfaction. | ||
- **Should**: This will improve quality/performance/etc. is but unlikely to affect functionality. If the developer doesn't want to do this they should write an explanation. | ||
- **Could**: Similar to **Should** but without the requirement for explicit justification. The developer can dismiss on the grounds that velocity is the priority at the moment. | ||
- **Nit**: Preference only, the developer can dismiss without any justification. | ||
|
||
### The Happy Path | ||
|
||
If the review passes then the reviewer should approve the change and either the reviewer or PR author should merge it. | ||
|
||
### Requesting Changes | ||
|
||
If the review fails the reviewer should request any changes (this issue is said to require rework) | ||
A developer should ideally pick up any rework PRs before starting new work | ||
When a developer is happy that a rework is complete they should press the re-request review button on the PR | ||
|
||
### Making Changes | ||
|
||
Reviewers should feel free to make small changes to a PR as part of a review e.g. typos, poorly named variables, fixing a test. However, if code has been changed in this way they need then need to run it past another developer (ideally the original developer). This means that no code is merged into main without being looked at by at least 2 people, ensuring collective responsibility for the codebase. | ||
|
||
### Dismissing Stale Reviews | ||
|
||
There may be times where one person requests changes on a PR, these changes are addressed and another person then approves it. In this case the PR still cannot be merged until the original review is dismissed. We're happy for people to dismiss stale reviews with the understanding that: | ||
|
||
- The new reviewer should check that the must and should comments have been addressed | ||
- If it's a big change it may still be worth the original reviewer looking again, if so they should make this clear to the original reviewer and the person that wrote the code | ||
|
||
## Joining the Review Team | ||
|
||
At least two members of the review team from two different DLS teams *must* approve adding a new member, neither of them can be on the new member's DLS team. At least one of the approvers should ideally be a senior engineer but this will not always be possible. | ||
|
||
In the event of a rejection the review team should provide concise and actionable feedback and set a date for re-consideration. | ||
|
||
### Criteria for New Members | ||
|
||
New members should be regular contributors to dodal and should have been "shadow-reviewing" approved reviewers for a period of weeks or months before becoming approved. In both their contributions and reviews they should be consistently demonstrating the following *without prompting*: | ||
|
||
- A good understanding of Python, including advanced langauge features such as [generators](https://wiki.python.org/moin/Generators), [coroutines](https://docs.python.org/3/library/asyncio-task.html), [comprehensions](https://www.geeksforgeeks.org/comprehensions-in-python/) and [pattern matching](https://peps.python.org/pep-0636/). | ||
- A pythonic coding style, demonstrated by using appropriate class/variable names, aherence to [PEP 8](https://peps.python.org/pep-0008). | ||
- Adherence to the review standards above as well as the [repository standards](../reference/standards.rst) and [device standards](../reference/device-standards.rst). | ||
- Independent (i.e. not just to satisfy a reviewer) motivation to make sure all code in dodal is well-tested. Use of unit and system tests as appropriate. Clear effort made to keep test coverage high (>90%). | ||
- Advanced understanding of bluesky and ophyd-async including concepts and best practices, such as how to appropriately split logic between devices/plans/callbacks. | ||
- Humility in the use of reviewing as a tool in a way that balances the need to preserve quality with the need for progress. Appropriate use of the Must/Should/Could/Nit system documented above is helpful in showing this, as it gives the reviewer the opportunity to weight their comments in terms of project impact. They should also demonstrate similar humiliary as a reviewee. | ||
|
||
Additionally, they should be regularly raising issues in the repository and demonstrating the ability to write well formed issues, with well defined acceptance criteria, that are understandable without large amounts of context. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,61 +1,30 @@ | ||
from dodal.common.beamlines.beamline_utils import device_instantiation, set_beamline | ||
from dodal.common.beamlines.beamline_utils import device_factory, set_beamline | ||
from dodal.devices.motors import XYZPositioner | ||
from dodal.devices.p99.sample_stage import FilterMotor, SampleAngleStage | ||
from dodal.log import set_beamline as set_log_beamline | ||
from dodal.utils import get_beamline_name | ||
from dodal.utils import BeamlinePrefix, get_beamline_name | ||
|
||
BL = get_beamline_name("BL99P") | ||
BL = get_beamline_name("p99") | ||
PREFIX = BeamlinePrefix(BL) | ||
set_log_beamline(BL) | ||
set_beamline(BL) | ||
|
||
|
||
def sample_angle_stage( | ||
wait_for_connection: bool = True, fake_with_ophyd_sim: bool = False | ||
) -> SampleAngleStage: | ||
"""Sample stage for p99""" | ||
|
||
return device_instantiation( | ||
SampleAngleStage, | ||
prefix="-MO-STAGE-01:", | ||
name="sample_angle_stage", | ||
wait=wait_for_connection, | ||
fake=fake_with_ophyd_sim, | ||
) | ||
|
||
|
||
def sample_stage_filer( | ||
wait_for_connection: bool = True, fake_with_ophyd_sim: bool = False | ||
) -> FilterMotor: | ||
"""Sample stage for p99""" | ||
|
||
return device_instantiation( | ||
FilterMotor, | ||
prefix="-MO-STAGE-02:MP:SELECT", | ||
name="sample_stage_filer", | ||
wait=wait_for_connection, | ||
fake=fake_with_ophyd_sim, | ||
) | ||
|
||
|
||
def sample_xyz_stage( | ||
wait_for_connection: bool = True, fake_with_ophyd_sim: bool = False | ||
) -> XYZPositioner: | ||
return device_instantiation( | ||
FilterMotor, | ||
prefix="-MO-STAGE-02:", | ||
name="sample_xyz_stage", | ||
wait=wait_for_connection, | ||
fake=fake_with_ophyd_sim, | ||
) | ||
|
||
|
||
def sample_lab_xyz_stage( | ||
wait_for_connection: bool = True, fake_with_ophyd_sim: bool = False | ||
) -> XYZPositioner: | ||
return device_instantiation( | ||
FilterMotor, | ||
prefix="-MO-STAGE-02:LAB:", | ||
name="sample_lab_xyz_stage", | ||
wait=wait_for_connection, | ||
fake=fake_with_ophyd_sim, | ||
) | ||
@device_factory() | ||
def angle_stage() -> SampleAngleStage: | ||
return SampleAngleStage(f"{PREFIX.beamline_prefix}-MO-STAGE-01:") | ||
|
||
|
||
@device_factory() | ||
def filter() -> FilterMotor: | ||
return FilterMotor(f"{PREFIX.beamline_prefix}-MO-STAGE-02:MP:SELECT") | ||
|
||
|
||
@device_factory() | ||
def sample_stage() -> XYZPositioner: | ||
return XYZPositioner(f"{PREFIX.beamline_prefix}-MO-STAGE-02:") | ||
|
||
|
||
@device_factory() | ||
def lab_stage() -> XYZPositioner: | ||
return XYZPositioner(f"{PREFIX.beamline_prefix}-MO-STAGE-02:LAB:") |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters