Oct / Nov ESC Meeting Minutes

[Luca Milanesio]

Hi all,

The ESC Meeting Minutes for Oct 2022 and Nov 2022 have been published to [1].

See here below for your convince what has been discussed and noted.

Luca.

— * —

Import of projects

Luca gave an overview of challanges faced when importing Gerrit projects. That includes server ID mismatches and change number clashes. The topic of portability of projects seems interesting to the wider audience, so the desire was for a design doc to be written.

Dedeprecation of change numbers

We discussed if integer change numbers should be dedeprecated. This will be clarified as part of the design doc on project imports.

Open vs. closed default settings

The default config grants read permission on refs/heads/*, which is practical for development and testing, but not a secure default for production use. Consensus that more secure defaults would be good; this could take the form of a init question, “do you want default open / default close” setting?

Gerrit 3.7 release

Gerrit RC 0 and RC 1 are out. Luca asks for help with writing release notes.

Gerrit user summit/hackathon

Finding space was hard; end of the pandemic caused a space crunch. Due to space constraints, no open call for participation to the hackathon. Summit is almost fully booked for in-person attendance. Google and SAP may give talks on recent work.

Community updates

The move to Discord from Slack has gotten positive feedback.

The new format for the community meeting (solicit a specific topic, discussion on that topic) has garnered a lively discussion in the last meeting.

— * —

[1] https://www.gerritcodereview.com/news.html

[Sven Selberg]

On Wednesday, January 4, 2023 at 3:34:08 PM UTC+1 lucamilanesio wrote:

Hi all,

The ESC Meeting Minutes for Oct 2022 and Nov 2022 have been published to [1].

See here below for your convince what has been discussed and noted.

Luca.

— * —

Import of projects

Luca gave an overview of challanges faced when importing Gerrit projects. That includes server ID mismatches and change number clashes. The topic of portability of projects seems interesting to the wider audience, so the desire was for a design doc to be written.

Dedeprecation of change numbers

We discussed if integer change numbers should be dedeprecated. This will be clarified as part of the design doc on project imports.

The actual deprecation of change-number could be a valid quest.

The "favored" change-key (as far as I understand) is $PROJECT~$BRANCH~$CHANGE_ID and one of its benefits is that you can derive this from a patch-set commit (since it's on a branch in a git project with an origin).
However looking up a change with this key has a performance and race-condition penalty since there's an extra step to map it to change-number that is used to look up the change-ref from which to look up the change (as we have discovered, with a fast message-queue we had services that attempted to lookup a change through this key before the index-document was available that maps this key to the change-number so that the ref can be looked up and hence got a 404).

For it to make sense to remove change-number we would have to rewrite and migrate the change-refs from "refs/changes/$SHARDED_CHANGE_NUMBER/..." to something like "refs/changes/$BRANCH_SLUG/$SHARDED_CHANGE_ID/...".

I don't think this rewrite is that crazy. And as a transition we could add change-number as an attribute to note-db (and remove Change-Id since it is then part of the note-db ref).
Once we have transitioned to the new change-ref we can remove change-nbr from URLs etc (with a mapping for change-number-URLs for the legacy changes that had one).

It would require quite a lot of pondering, elbow-grease and verification to clean up this legacy technical debt, so it would require an extensive acceptance and review-effort from the community before anyone would even starts which might make it implausible.

[Luca Milanesio]

On 4 Jan 2023, at 16:17, Sven Selberg <sven.s...@axis.com> wrote:

On Wednesday, January 4, 2023 at 3:34:08 PM UTC+1 lucamilanesio wrote:

Hi all,

The ESC Meeting Minutes for Oct 2022 and Nov 2022 have been published to [1].

See here below for your convince what has been discussed and noted.

Luca.

— * —

Import of projects

Luca gave an overview of challanges faced when importing Gerrit projects. That includes server ID mismatches and change number clashes. The topic of portability of projects seems interesting to the wider audience, so the desire was for a design doc to be written.

Dedeprecation of change numbers

We discussed if integer change numbers should be dedeprecated. This will be clarified as part of the design doc on project imports.

The actual deprecation of change-number could be a valid quest.

The "favored" change-key (as far as I understand) is $PROJECT~$BRANCH~$CHANGE_ID and one of its benefits is that you can derive this from a patch-set commit (since it's on a branch in a git project with an origin).
However looking up a change with this key has a performance and race-condition penalty since there's an extra step to map it to change-number that is used to look up the change-ref from which to look up the change (as we have discovered, with a fast message-queue we had services that attempted to lookup a change through this key before the index-document was available that maps this key to the change-number so that the ref can be looked up and hence got a 404).

For it to make sense to remove change-number we would have to rewrite and migrate the change-refs from "refs/changes/$SHARDED_CHANGE_NUMBER/..." to something like "refs/changes/$BRANCH_SLUG/$SHARDED_CHANGE_ID/...".

I don't think this rewrite is that crazy. And as a transition we could add change-number as an attribute to note-db (and remove Change-Id since it is then part of the note-db ref).
Once we have transitioned to the new change-ref we can remove change-nbr from URLs etc (with a mapping for change-number-URLs for the legacy changes that had one).

Hi Sven,

I’ll add you as reviewer to the current design document in WIP / Review at [1].

The proposal *would not* require any history rewrite or migration process: that is for allowing zero-downtime upgrades and adoption of the new scheme.

It would require quite a lot of pondering, elbow-grease and verification to clean up this legacy technical debt, so it would require an extensive acceptance and review-effort from the community before anyone would even starts which might make it implausible.

I actually started already working on that and the effort is less than what is looks like :-)

But yes, a lot of review is definitely needed.

Luca.

[1] https://gerrit-review.googlesource.com/c/homepage/+/354234

Open vs. closed default settings

The default config grants read permission on refs/heads/*, which is practical for development and testing, but not a secure default for production use. Consensus that more secure defaults would be good; this could take the form of a init question, “do you want default open / default close” setting?

Gerrit 3.7 release

Gerrit RC 0 and RC 1 are out. Luca asks for help with writing release notes.

Gerrit user summit/hackathon

Finding space was hard; end of the pandemic caused a space crunch. Due to space constraints, no open call for participation to the hackathon. Summit is almost fully booked for in-person attendance. Google and SAP may give talks on recent work.

Community updates

The move to Discord from Slack has gotten positive feedback.

The new format for the community meeting (solicit a specific topic, discussion on that topic) has garnered a lively discussion in the last meeting.

— * —

[1] https://www.gerritcodereview.com/news.html

-- 
-- 
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/d5e7d3d8-dae4-4dbc-86cc-92b88eaf0325n%40googlegroups.com.