Arrange How We'll Work Here and Collaborate With Upstream #2
Comments
RandomDSdevel
added
enhancement
|
Short term, overriding Long term, their changes to building packages (no more options?!) for v2 might force us to diverge. |
|
@rw:
There would, at least initially, likely remain a non-trivial number of commits we could keep in common, however, and I'd want to make maintaining that |
|
With respect to branch organization here in portage-brew/brew, here, tentatively, is what I have set up for now:
I haven't quite hammered out whether our PRs should be against our ' |
|
An update: I've reorganized which branches have which others as upstreams. Here's the new tentative layout:
Having our '
I'm uncertain how this interacts, if at all well, with pulling commits from our ' |
|
Also, in case it wasn't clear, I want to have tooling and/or automation set up to ease maintaining whatever we settle on here. |
Options aren't going away in brew, just in the core repo. |
|
I'm the lead of maintainer of Linuxbrew/brew, which has been a fork of Homebrew/brew for about five years. Each stable release of Homebrew, I merge the stable tag (say |
We know, but see portage-brew/portage-brew-staging-and-evolution#8 and #1. |
|
So you don't have any analog of our ' |
|
Correct. We merge only stable upstream releases into our |
|
OK, that makes things simpler. I'll implement that soon. |
|
All right, here's what I have now:
I'm leaving this issue open until we tackle tooling/automation, however. |
|
|
|
Thought I'd seen that as a convention somewhere, codifying/mirroring the terminology. Eh, it can always get renamed later to be more clear if need be. |
So long as you configure Edit: Change |
|
You mean ' |
|
Typo. I meant |
|
No worries; I do it sometimes, too! |
|
I thought it'd be more appropriate to comment here than start a new issue on this: I think it'd be wise to document some of the architecture of homebrew, either as a part of this project or as a part of another project in this organization. The chief impetus is that homebrew org doesn't seem to make public much of their design except in raw ruby. It seems an odd half-measure between cathedral and bazaar styles, there. Anyway, I say this because I think it'd help lower the barrier to contributing in a meaningful way. At the very least, some simple I have some informed guesses I could make about its structure and interaction. For example, just sampling a few commits, it looks like the maintenance of most formula revolves around incrementing the version number and updating the hashes. That doesn't do a whole lot to tell me in which files I should read the relevant source, though. I am a student with a full-time job commitment on top of that, so I'm not sure how much I could help, frankly. And perhaps it's wildly unhelpful to be spitballing as an idea-guy. I just know that it seems super intimidating from my perspective to even begin to understand where things should be worked on. |
|
I'm a maintainer of Homebrew. I'm happy to answer specific questions that you may have about the architecture of Homebrew. In the mean time, there's a fair amount of information in the docs: https://docs.brew.sh particularly https://docs.brew.sh/Formula-Cookbook |
> Bootsnap is a library that plugs into Ruby, with optional support > for ActiveSupport and YAML, to optimize and cache expensive > computations. https://github.com/Shopify/bootsnap For our case that translates to "repeated calls to `brew` have reductions in the time spend `require`ing speeding up the process boot time". For example: ``` $ hyperfine --warmup=2 "unset HOMEBREW_BOOTSNAP; brew info wget" "export HOMEBREW_BOOTSNAP=1; brew info wget" Benchmark #1: unset HOMEBREW_BOOTSNAP; brew info wget Time (mean ± σ): 2.417 s ± 0.032 s [User: 659.0 ms, System: 855.5 ms] Range (min … max): 2.382 s … 2.464 s 10 runs Benchmark #2: export HOMEBREW_BOOTSNAP=1; brew info wget Time (mean ± σ): 1.862 s ± 0.064 s [User: 425.3 ms, System: 566.8 ms] Range (min … max): 1.736 s … 1.952 s 10 runs Summary 'export HOMEBREW_BOOTSNAP=1; brew info wget' ran 1.30 ± 0.05 times faster than 'unset HOMEBREW_BOOTSNAP; brew info wget' ```
Port `brew --version` to Bash to speed it up. While we're here: - remove (now) unused `Tap` Git methods - use `--quiet` instead of `-q` to be more verbose Benchmarks: ``` $ hyperfine --min-runs=3 --warmup=2 "git checkout origin/master; brew --version" "git checkout speedup_brew_version; brew --version" Benchmark #1: git checkout origin/master; brew --version Time (mean ± σ): 2.083 s ± 0.004 s [User: 396.8 ms, System: 597.2 ms] Range (min … max): 2.080 s … 2.088 s 3 runs Benchmark #2: git checkout speedup_brew_version; brew --version Time (mean ± σ): 847.9 ms ± 35.2 ms [User: 100.0 ms, System: 247.9 ms] Range (min … max): 824.1 ms … 888.3 ms 3 runs Summary 'git checkout speedup_brew_version; brew --version' ran 2.46 ± 0.10 times faster than 'git checkout origin/master; brew --version' ```
I'm initially somewhat inclined to want to work off of upstream's latest stable released tag (by tracking a '
stable' branch like what I have set up locally) and rebase as needed, but we could also work off of 'master.' Regardless, we need to find some way to make it easy to stay abreast of upstream commits, or at least most of them and/or the ones we'd be interested in. I also want us to consider how we'd upstream commits if we decided to do so for any before fully upstreaming our work here.The text was updated successfully, but these errors were encountered: