haskell-updates: add documentation for workflow #122728
Conversation
|
I plan on continuing to update this document while I work on getting #122719 ready to merge in. I will try to document everything I do in detail. |
|
This should be ready for review. I'd especially appreciate reviews from @maralorn and @sternenseemann. Feel free to rewrite/add anything. |
| ### Additional Info | ||
|
|
||
| Here are some additional tips that didn't fit in above. |
There was a problem hiding this comment.
At some point I'd like to add a section about marking packages broken on architectures other than x86_64-linux, but since we haven't really come to a conclusion on what to do about that, I haven't added it to this document.
| ## Contributor Workflow | ||
|
|
||
| (TODO: this section is to describe the type of workflow for non-committers to | ||
| contribute to `haskell-updates`) |
There was a problem hiding this comment.
I plan on trying to write this at some point in the future.
Possibly either during Zurihac, or the next time it is my turn to take care of the haskell-updates workflow.
There was a problem hiding this comment.
We should probably move the contributor workflow to the nixpkgs manual as well then. Not sure if the maintainer workflow belongs there though (probably not, as similar documentation like the release manager documentation is also managed separately)
There was a problem hiding this comment.
I don't really like the "out of sight, out of mind" quality of the nixpkgs manual. I think it is way too easy not to update documentation when it doesn't live near the code.
However, I agree that it probably does make the most sense for the contributor workflow to live there.
|
Do you want this to be merged now? I would be okay with saving this and improving on it. In the future we definitely need a consistent concept on how this documentation relates to the manual. |
| ## Contributor Workflow | ||
|
|
||
| (TODO: this section is to describe the type of workflow for non-committers to | ||
| contribute to `haskell-updates`) |
There was a problem hiding this comment.
We should probably move the contributor workflow to the nixpkgs manual as well then. Not sure if the maintainer workflow belongs there though (probably not, as similar documentation like the release manager documentation is also managed separately)
| merging the `haskell-updates` branch into `master`. | ||
|
|
||
| The goal of this workflow is to regularly merge the `haskell-updates` branch | ||
| into the `master` branch, while making sure there are no evaluation errors or |
There was a problem hiding this comment.
I'd clarify this: A broken package technically fails to evaluate. I guess the main properties are currently:
- No inacceptable regressions in terms of build failures (maintained, mergeable, ...)
- No non-broken package that fails to build (on x86_64-linux)
Might've missed something?
There was a problem hiding this comment.
I don't think this necessarily needs to be clarified in the overview here.
However, below there is a section called "Merge haskell-updates into master". It explains that all Haskell packages that fail to build should be marked broken, as well mentioning the maintained and mergeable jobs.
I'm going to go ahead and merge this in, but if you want to clean up that section (or even this overview/introduction), please feel free to either leave a message here or just commit directly to haskell-updates.
| - The maintainers for any maintained Haskell packages that are newly broken | ||
| have been pinged on GitHub and given at least a week to fix their packages. | ||
| This is especially important for widely-used packages like `cachix`. | ||
|
|
There was a problem hiding this comment.
As per yesterday's discussion, we should make it a point here to merge master into haskell-updates and waiting for the rebuilds to finish before merging the PR.
There was a problem hiding this comment.
Especially since I realized: Merging in master and hitting "eval" on hydra and seeing if anything new happens is really only a matter of a few minutes. I think we can afford to do that on every merge.
There was a problem hiding this comment.
I've rearranged this in adfec8b. Hopefully it is somewhat more clear now.
|
Note to myself: probably should also add a explanation of running Another note: probably should add a comment that we all hang out on Matrix. |
Co-authored-by: sterni <sternenseemann@systemli.org>
cdepillabout
force-pushed
the
haskell-updates-workflow
branch
from
7ea2cc7
to
bd6a1e1
Compare
…broken package list
…erging master into haskell-updates
I've done this in commit 95e7f26. I'm going to go ahead and merge this in, but if you guys want to comment on or fix up anything else, please continue to leave comments here and I will commit changes to this document directly to the |
This some documentation for is the workflow for the
haskell-updatesbranch. This would mostly be a reference for @maralorn, @sternenseemann, and me. This would also be useful if someone else joined the nixpkgs haskell maintainer group.I welcome any bikeshedding on what to name this document or where to put it.
This document will mostly be based on the comment from @maralorn in #122510 (comment).
This is related to #121403.
Rendered