I’ve started creating a page for Project standards and would love if some people contributed ideas about what all we think the standards should be. I think what is up there so far is realistic, but I think it could use some more meat.
For example, do we want to have stuff about commit messages on there?
Extreme nitpick, but you made a typo
A devnev when applicable
Currently working my way towards bed. But feel free to fix it. If it’s there tmrw afternoon I’ll worry about it.
fixed, thanks (filler text)
If I understand correctly, I believe the goal is to squash and merge PRs, right? I think it would be very helpful to define a format for merge commit messages like feat
, fix
, break
, etc. Guidance around commit messages describing the goal of the code/change would also be helpful from an effective PR review perspective.
I think we can mostly pinch prior art from Nixpkgs for that. Their messages are pretty nicely formatted, IMO.
Thanks for pointing to that, I’m new to the whole ecosystem.
Seems like the labels there indicate where the commited code is going pkgs
, lib
and not what it does: bug fix, security fix, new feature. Has that worked fairly well so far?
Also, what’s the thought on using tooling like pre-commit instead of using reminders?
Instead of:
Check for unnecessary whitespace with
git diff --check
before committing.
Have this:
repos:
#could (should?) be a Auxolotl repo
repo: https://github.com/pre-commit/pre-commit-hooks
rev: v2.3.0
hooks:
- id: end-of-file-fixer
- id: trailing-whitespace
My biggest gripe with pre-commit is that they are system dependant. I know to most that probably won’t matter since your all working from WSL, darwin or linux. But sometimes we don’t get a choice but to work on windows.
this is a bad idea in the context of package repos. it will give contributors much more difficulty in bisecting history
the commit messages/PR titles should describe what it does. for example, a pr named foo: 1.0.0 -> 1.0.1
doesn’t really need a label
i’d say so. nixpkgs’ labeling system is one of the more useful things i’ve found in a github repo, along with the good standard of commit messages. makes it very easy to see what has been reviewed with approvals
labels, if it’s something you’re knowledgeable of with topic
labels, and how taxing a nixpkgs-review run would be with ofborg’s rebuild-linux
and rebuild-darwin
tags
no go. we should require as little as possible on a contributors system, and in general i don’t see a need to depend on an external tool that will require additional setup
for cases like these it would be much easier to just use workflows to check PRs. this would require no setup for contributors (which as said before, is pretty important) and make issues easily available to them and other from anywhere
I’m also advocating for that “pkg:
foo update” isn’t helpful. Agreed.
That’s great, it achieves the same thing of not making it a reminder but using tools to enforce process. I understand the reduction of dependency for contributors but it’s unfortunate that it’s not friction free (the workflow will find the issue but not fix it). It’s a lament, not a gripe.
That is unfortunate, didn’t realize it didn’t work in Windows.
To be honest I went with the windows example. But pre-commit hooks work differently on all systems. Its just that it is more noticeable on windows since some software’s don’t work on there.
I’ll take your word for it, I don’t have experience using it on a variety of platforms. It’s running through a Python runtime so it’s interesting that it’s so system dependent. I’ll keep that in mind if I need to use it on other systems and test/research thoroughly. Thanks for the heads up.
Alright I’ll add commit messages for pushes & merges later today
I think I’ve added some sensible stuff for commit messages, feel free to message in here if anyone thinks there should be some changes
Maybe deciding the formatting tool used for new auxolotl contributions while it’s not too late would be nice.
I personally use and like more alejandra
than nixfmt-rfc-style
I believe all the python code present in nixpkgs should be formatted using black
which is literally the open source standard formatter
yep. black follows pycodestyle to a T so I’m in agreement