trezord: 2.0.14 -> 2.0.19 and nixos/trezord: revised and updated udev rules #46656
Conversation
|
closing as duplicate of #46658 |
|
Target branch is master, not 18.03 (it's not a duplicate). Should I use some different method for opening pull request into different branch? |
|
I think this should be reopened, maybe the |
maintainers."1000101"
|
Sorry, I didn't realize you had a different target branch! |
|
No worries! If there's a better/preferred way, just let me know! |
|
Hm. Probably: put something into the PR caption for non-master PRs (because GitHub UI makes it annoying to navigate three same-name adjacent-numbered PRs). Also for backports it might be a good idea to confirm if it is a backward-compatible release with notable bugfixes (or if it is a not-fully-compatible release with major bugfixes — vulnerabilities or just major bugs, doesn't matter). Also, I guess in general for small changes that are easy to review all at once having just one commit is OK, having a commit per step is also OK, but having a commit with a mistake and a separate commit with a fix is considered undesirable. |
7c6f434c
added
8.has: package (update)
11.by: upstream-developer
8.has: module (update)
and removed
8.has: module (update)
labels
Thanks, should I close this pull request and open a new one with all your comments incorporated?
On IRC, I was told to make separate commits when updating separate files so it would be easier to track the changes. Sorry for that. Is there anything more I should do in order to speed up the potential merge? Thanks. |
|
> Also for backports it might be a good idea to confirm if it is a backward-compatible release with notable bugfixes (or if it is a not-fully-compatible release with major bugfixes — vulnerabilities or just major bugs, doesn't matter).
Thanks, should I close this pull request and open a new one with all your comments incorporated?
GitHub allows force-pushes to PR branches; it definitely allows to edit the caption and the description of the PR.
> Also, I guess in general for small changes that are easy to review all at once having just one commit is OK, having a commit per step is also OK, but having a commit with a mistake and a separate commit with a fix is considered undesirable.
On IRC, I was told to make separate commits when updating separate files so it would be easier to track the changes. Sorry for that. Is there anything more I should do in order to speed up the potential merge? Thanks.
Separate commits per small change is a fine development practice, I was only talking about a pure typo-fix as a separate commit. When larger changes are requested, some people seem to prefer a force-push with a logical representation of the resulting set of changes and some prefer additional commits with new changes (so the old changes are kept intact), it depends on the people involved.
|
|
will require further testing for model T |
Motivation for this change
I'd like to maintain the package up-to-date as we're the company releasing the original code.
Things done
Updated version from 2.0.14 to 2.0.19. Reviewed and updated the service policies and rights.
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)