-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Barretenberg in monorepo #1126
Labels
A-internal-devex
Area: Relates to the devex of internal teams building Aztec.
Comments
ludamad
added
the
A-internal-devex
Area: Relates to the devex of internal teams building Aztec.
label
Jul 20, 2023
ludamad
added a commit
that referenced
this issue
Jul 24, 2023
See #1126 for motivation. Merge remote-tracking branch 'barretenberg/master' into combined_history
ludamad
added a commit
that referenced
this issue
Jul 24, 2023
This implements "Integrate barretenberg code and CI situated at circuits/cpp/barretenberg" in #1126. The motion to include barretenberg in the monorepo has not had major opposition, though for sure there was hesitation around the disruption and effort. Minor opposition was noted around the repo barrier and CI times, but overall we believe we can solve these issues.
Good progress on this but I'll hold off until full CI port |
CI has been fully ported, marking done |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For smoother developer experience we have decided to roll https://github.com/AztecProtocol/barretenberg into the aztec monorepo (i.e. this repo).
Upsides:
Downsides:
Planned actions:
Critical: We want barretenberg to remain something we think very consciously about modifying as it must be audited effectively. The most important part of the audit process is the dev cycle. It is important to ensure that confidence in the code by barretenberg's core devs is maintained.
Also see task list.
Original message in the experiment PR
"This has a good deal of buy-in at this point. If we want outward facing
repos, we can do it programmatically without breaking atomicity.
Our ideal mindset until closer to launch is to have everyone thinking
what brings the most value incrementing the system,
which implicitly means moves that cross the most dimensions
inherently go farther. A real and frequent example is changing a concept
on our whole stack at once, e.g a new builtin, different proving system
iteration having a different ideal interface etc."
Tasks
The text was updated successfully, but these errors were encountered: