Yep, I agree that SIGs will know and control their domain the best. Reaffirming their authority here in case anyone wasn’t sure 
4 Likes
Oh yeah, I meant for just docs, not everyone rn.
@isabel quick question, when I’m merging PRs, is there a preference between merging vs rebasing that I should follow?
For what it’s worth, I personally like the “squash-and-rebase” process - it leads to a clean, linear master branch where one commit can be mapped directly to one PR, which makes it easy to link changes in code to the discussions around them in PR reviews, and associated links in PRs. Would love to hear suggestions from others though.
6 Likes
This is my personal preference as well, but I just realized that I’ve been punching the merge button out of habit because of work so I thought I’d check in and make sure it was okay for me to rebase. 
1 Like
nixpkgs already more or less enforce squashing to a single commit before merging. There’s not much gained from creating explicit merges for that.
More complex work I absolutely prefer to have explicit merges for. The purpose of the commit history is not to look pretty, but to provide real help when debugging or otherwise investigating after the fact. If everything is a bunch of tangentially related changes across a bunch of files then that is really an uphill struggle for the person reviewing history.
A squash & rebase at that point has prioritized the vanity of the committer over the sanity of the maintainer, which is never in the interest of the project 
So I suppose we’re either at the usual “it depends” or a preference for no squashing - to be on the safe side. I would assume at this stage we can deal with the former just fine and then later at scale the other option can be held as a fallback if good judgement starts to falter?
3 Likes
Yeah like the other who have already commented I prefer *squash-and-rebase"
1 Like
Should we change pull bot to do merge commits instead of rebases?
Hummm, I still think rebases are better. But if you can argue why ill certainly hear you out
1 Like
I can’t really think of a reason off the top of my head.
I’m gonna go ahead and resolve the conflict in that PR if that’s all fine.
I suspect we’re going to run into a lot more of these.
I was just about to do it myself. But go ahead ill check when your done. Let me know if you need help.
100%
1 Like
We should avoid making any changes at all to the nixpkgs fork, IMO - any changes we want to make to the nixpkgs set should be made within the Packages/Core repo.
Speaking of which, do we maybe want to re-evaluate the name of that repo? I’ve personally been calling it “core”, despite it being named “packages” - unsure what the current consensus on this is.
Yes I think we should rename it to core following the rest of the changes to the other repos, or the current structure if you prefer. And we actually have a number of changes on the nixpkgs repo so what should we do for those pull them out?
I would prefer that we keep making changes to our nixpkgs fork until we are ready for a hard fork at which point we start breaking our packages up into their respective domains (SIG).
My concern with this approach is that as we introduce more changes on top of Nixpkgs, we increase the likelihood and amount of merge conflicts that come in every time we want to resync with upstream - hence why I was thinking of moving things into SIG repos ASAP, so we don’t have to deal with the (potentially very high) maintenance overhead of keeping our patchset ontop of Nixpkgs.
Definitely interested to hear suggestions on ways we can ease that burden while still keeping changes in Nixpkgs for now - I think that would be an ideal outcome, I’m just not sure how to achieve it.
1 Like
My concern with this approach is that as we introduce more changes on top of Nixpkgs, we increase the likelihood and amount of merge conflicts
I mean this was already likely the current merge conflict we have is because of upstream, not because of our local changes.
moving things into SIG repos ASAP, so we don’t have to deal with the (potentially very high) maintenance overhead of keeping our patchset ontop of Nixpkgs.
It would be amazing to break out some of the packages now and try to keep them as up to date as possible but with our limited team that would be very hard
The SIG repos could be a directory structure of patch sets for now. That would seem to bridge the two concerns and maintain momentum?
1 Like