| Age | Commit message (Collapse) | Author |
|---|
|
The big ones here are `trim-trailing-whitespace` and `end-of-file-fixer`
(which makes sure that every file ends with exactly one newline
character).
Change-Id: Idca73b640883188f068f9903e013cf0d82aa1123
|
|
I didn't enable this by default for clang due to making the build time
10% worse or so. Unfortunate, but tbh devs for whom 10% of build time is
not *that* bad should probably simply enable this.
Change-Id: I8d1e5b6f3f76c649a4e2f115f534f7f97cee46e6
|
|
hacking changelog-d to support not just github but also forgejo and
gerrit is a lot more complicated than it's worth, even moreso since
the entire thing can just as well be done with ~60 lines of python.
this new script is also much cheaper to instantiate (being python),
so having it enabled in all shells is far less of a hassle.
we've also adjusted existing release notes that referenced a gerrit
cl to auto-link to the cl in question, making the diff a bit bigger
closes https://git.lix.systems/lix-project/lix/issues/176
Change-Id: I8ba7dd0070aad9ba4474401731215fcf5d9d2130
|
|
This uses the forgejo patch we have for dont_notify on issue creation on
the api, and indeed does not notify, so we can simply run the script
safely :D
Fixes: https://git.lix.systems/lix-project/web-services/issues/38
Change-Id: I86bcbf9b4499b439b79b82af84ee7df0f8eb3298
|
|
Turns out also, you cannot set the queue to 0 with any success. So we
really should just like, prevent notifications in forgejo itself.
Filed a bug for that:
https://git.lix.systems/lix-project/web-services/issues/38
Change-Id: Ib96749f3159659182904963cab7b2ef88fc64442
|
|
We needed a script to go yoink all the real NixOS/Nix issues from our
mirror into the Lix repo.
Change-Id: If8c8ebfb58634c675eae450454c0189288c6b18a
|
|
Automatically compile hand-written release notes with `changelog-d`
(cherry picked from commit 928f0c13414d20c1af88b30bd6700fd730ee0bab)
Change-Id: Ia0685835c52edf185b64dd696b19305746c077e5
|
|
as discussed with maintainers team
|
|
Fixes #8451.
|
|
|
|
https://github.com/NixOS/nixpkgs/pull/235463
|
|
|
|
|
|
this allows easier linking and a provides a bit more visual clarity
|
|
|
|
review process: all PRs must be triaged
|
|
the team perceives triaging literally everything as too much overhead,
and there is a desire to allow for more parallel action.
|
|
in order to make the development process more transparent for everyone,
all pull requests should go through the triage process before getting
merged.
this ensures that all team members are aware of what is going on, and
that rationale for decisions is kept track of in the meeting notes for
posterity. (ideally all that should go into the commit history, but this
is a more invasive process change that needs further deliberation.)
having all team members take at least a brief but conscious look at each
change may also help with keeping our quality standards, as more
reviewers are more likely to remind each other of our shared values.
|
|
PRs that don't increase our ongoing obligations (i.e. by adding new
features) but do increase test coverage of existing features are good
things to merge for the health of the project, and thus good to
prioritize.
|
|
add objectives and tasks for Nix team
|
|
add @Ericson2314 to the Nix team
|
|
|
|
|
|
so far there were no even remotely measurable objectives, only a general
purpose statement.
this change is intended to focus the team's work on what I (and many
others I talked to) perceive to be the main pain point in the
development process.
Co-authored-by: solene.rapenne@tweag.io
|
|
Document the release process
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
Closes #7623
|
|
based on
- Nix team decisions
https://discourse.nixos.org/t/2022-11-11-nix-team-meeting-minutes-7/23451#planning-discussion-1
https://discourse.nixos.org/t/2022-12-02-nix-team-meeting-minutes-13/23731#discussion-3
- proposal to deal use labels more effectively
https://discourse.nixos.org/t/improving-nix-developer-experience/21629
- documentation team decision to foster gauging interest using upvotes
https://github.com/NixOS/nix/pull/7387
|
|
|
|
John has been part of every meeting since the beginning.
He took on a lot of work on behalf of the team, and provided useful suggestions in discussions, advocating for stability, reasonable design decisions, and maintainable code.
He was in general highly productive within the team process, and repeatedly helped us to keep focus on our stated goals.
Specifically, early on he suggested to gather more experience with the team reviews in order derive our values for the project encode a more structured approach to guiding contributions, which is slowly bearing fruit these days.
John is already the contributor with the most code changes to date (only topped by principal author Eelco), and is well-known to be highly knowledgeable about both high-level design and low-level internals of the code base.
He has continued to offer high quality work during the team's operation, which resulted in many pull requests getting merged that further the team's goals.
It is due time for John to be come an official team member and be granted merge access that he will surely exercise with the great care he is known for.
|
|
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|
Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|
|
|
|
|
Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
|
|
Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
|
|
|
|
|
|
This makes it easier for others to make releases, and probably few
people care about GPG signatures anyway.
|
|
|
|
|
|
|
|
write down the process we have been developing and following so far.
Co-Authored-By: Théophane Hufschmitt <theophane.hufschmitt@tweag.io>
Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
|
|
This also makes sure that we get the Docker images from the same Hydra
eval, rather than the latest build from job/nix/.../dockerImage, which
may not be the same.
|
|
|
|
|
|
|
|
|
|
|
|
|
