Keep individual commit log instead of aggregating releases

[fhoering]

Currently each release bundles the commits from internal Google git servers into a giant commit:

Release 4.0.0 (2024-09-09) · privacysandbox/bidding-auction-servers@722e154

To allow easier reviewing, trackability and troubleshooting each commit should be available individually on github.

It is the case for commits on the key value server on the main branch and keeping things stable by targeting the latest release branch by default (release-0.17)

Any idea why the workflow has been changed ?

[xinggao01]

Hi Fabian,

Thanks for your comment. You're right that key-value-service and bidding-auction-servers follow different approaches. One key difference is that bidding-auction-servers releases more frequently (weeks vs. months).

In key-value-service, the main and release branches are detached, whereas bidding-auction-servers maintains a tree structure. some may prefer one over the other.

Reviewing and tracking are better done at the release level because our commit history contains more noise. The same applies to troubleshooting, since each release undergoes thorough verification.

Could you share more about your use cases for granular commit history?

[fhoering]

Reviewing and tracking are better done at the release level because our commit history contains more noise.

Best practices of open source projects are to make granular commits and review and validate each commit.
Aggregating commits will hide information from external reviewers that is only available internal to Google. Having noise in commits may be an indicator for code quality issues.

I think, as this code base needs to be trusted open source best practices should be adopted. Potentially review tools like chromium's gerrit https://chromium-review.googlesource.com/q/status:open+-is:wip or github pull requests could also be used.

How do you plan on including external contributions (like bug fixes or up streamed changes from ad selection API) if the development branch is not available to the public ?

[xinggao01]

We develop our code at a fast pace, which can sometimes result in commits that may later be reverted or modified. However, I don't see this as a "code quality issue".

Regarding "hide information," I believe there may be a misunderstanding. In our aggregated commits, all intended code changes are included and released transparently.

As for external contributions, we already support them. You can submit a pull request to the main branch, and after evaluation, it may be included in next release. Here's an example for reference.

1c32ad4

[webmihir]

Fabian, I agree with your suggestion and our goal is to get to similar level of accepting PR commits as Chromium. However B&A test and commit infra is currently not setup for this.

At this time we are not in a position to accept large scale commits due to this, however we may be able to consider one-off small commits as Xing mentioned above.

All our code changes are transparent and visible. This can be verified by building and matching the PCR0 hashes.