Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CONTRIBUTING.md: Improve backport instructions #85727

Merged
merged 1 commit into from Apr 27, 2020
Merged

Conversation

davidak
Copy link
Member

@davidak davidak commented Apr 21, 2020

Came up in #85723 (comment).

Copy link
Contributor

@worldofpeace worldofpeace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems good

@worldofpeace
Copy link
Contributor

@davidak No where does this mention that someone could be backporting multiple commits.
So maybe commit -> commit/s?

@davidak
Copy link
Member Author

davidak commented Apr 22, 2020 via email

@FRidh
Copy link
Member

FRidh commented Apr 22, 2020

I am not sure whether we should describe how to use git. While I can understand having a full set of instructions can be helpful to newcomers that are also somewhat unfamiliar with git, people use git differently. For example, I typically work with a detached HEAD, and push to refs/heads/<somebranch> without creating a local branch first.

Not saying it's not correct, but keep it in mind when writing instructions.

@7c6f434c
Copy link
Member

7c6f434c commented Apr 22, 2020 via email

@FRidh
Copy link
Member

FRidh commented Apr 22, 2020

What you write depends on which assumptions you make about the reader.

If we take your first group, and elaborate the instructions further (copy-paste quality), then one is going to have to consider more details such as the remote. How did they clone the repo? From a Nixpkgs GitHub fork or not? By not writing about how to branch/push we can avoid having to go there.

@7c6f434c
Copy link
Member

How did they clone the repo? From a Nixpkgs GitHub fork or not?

Looking at the entire instruction and the manual — at least in a way that pushes go to the fork.

I agree we are not aiming at copy-paste quality here (at least not yet), and maybe a more realistic goal is to aim at unambiguity where enough is said to be sure one is doing what is expected (or to be unsure what exactly to do and go ask…)

@davidak
Copy link
Member Author

davidak commented Apr 22, 2020

people use git differently.

a more realistic goal is to aim at unambiguity

yes, that was my goal. currently the instructions in the README and Manual produce different results

and even tho i work every day with git, i use cherry-pick just for backporting in nixpkgs which i don't do that often. so i just followed the instructions and committed to my local release-20.03. the branch is wasted now :( the proposed change would help here. we don't really need the git push command there, that's basic git

is it encouraged to backport multiple commits in a PR? for example 20 package updates? or 6 changes to NixOS modules that fix problems? or only with small fixes?

@davidak
Copy link
Member Author

davidak commented Apr 26, 2020

I updated the commit policy to reflect the current practice in #86026 and updated the backport instructions accordingly.

@Mic92 Mic92 merged commit c32c613 into NixOS:master Apr 27, 2020
@davidak davidak deleted the patch-2 branch April 27, 2020 10:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants