26th August 2026 - GitProxy Roadmap meeting Minutes

[kriswest]

Date

20260826 - 4pm BST / 11am EDT

Meeting info

• Meeting link

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

• Convene & roll call (5mins)
• Display FINOS Antitrust Policy summary slide and review Meeting Notices (see above)
• Approve past meeting minutes
• Git Proxy Roadmap discussion
  • 5 mins per team on goals for the project
  • Recently opened issues
  • Start planning
• AOB, Q&A & Adjourn (5mins)

Git Proxy Project – Consolidated Roadmap Summary

This document consolidates the key roadmap priorities shared by all participating firms at the recent meeting, together with relevant GitHub comments and discussions. Items marked as high-priority have broad and/or repeated support across multiple firms and should be considered for early focus in the next phase. Other items are proposed by one or more firms and may warrant further discussion on value and sequencing - i.e. the numbering below does not provide a relative priority - that still needs to be established.

Key Roadmap Items

1. Event Hook and Notification System (High Priority)

• Complete and mature the event hooks system to support notifications for key events (e.g., review required, approval, push/pull).
  • Email, Slack, and Teams notification support.
  • Expose all necessary event fields to enable rich notifications.
  • Plugin-friendly: event hooks should be extensible via plugins.
  • Ensure event handling does not impact subsequent events (idempotency, isolation).
• Provide a plugin-style approach for extending event handling and notifications.

2. Plugin System Extensions and Refactor (High Priority)

• Complete refactoring of plugin architecture:
  • Support plugins at more phases of the processing chain (not just ‘chain’ plugins).
  • Support for non-chain plugins and event-based plugins.
  • Clear interfaces and extension points to avoid the need for forking.
  • Use-case: supply chain scanning, custom integration, training checks.
• Reduce divergence of forks by enabling more types of plugins.

3. Supply Chain Security and Dependencies (High Priority)

• Achieve and maintain zero known CVEs in all dependencies.
  • Regular package updates and vulnerability scans.
  • Address outcomes from OSTIF and AI-based scanning reports.
• Better support for TLS (OpenShift hand-off, improved container handling).

4. UI Improvements and Accessibility

• Review and remediate accessibility issues in the new UI (@goldensyntax leading).
• Ensure built UI files are included in NPM releases (see UI files are not present in 2.0 and 2.1 NPM packages #1704).
  • Add CI tests to validate UI availability in packages.
• Automate or improve test coverage for UI build/publish pipeline.

5. Extended Open Source Lifecycle Governance

• Extend Git Proxy functionality to cover additional GitHub activities:
  • Ability to create issues, comments, and pull requests through Git Proxy.
  • Optional review processes and auditable logs for these activities.
  • Pre-approve PR content and better handling for subsequent pushes (branch intelligence, replace/close old reviews).

6. Account and Project Onboarding Improvements

• Enable better admin and self-service onboarding:
  • Allow admins to create users and assign roles before initial login.
  • Automate onboarding of new projects, with appropriate checks/reviews.
  • Configurable contribution policy requirements (e.g. training, documentation upload, admin approval).
  • Event hooks/plugins for onboarding triggers and policy enforcement.
  • Health warnings and auditable logs for project ingress.
  • Fork creation and management as a first-class feature (organisation-owned forks, fork clustering, sync forks).

7. Database and Deployment Support

• Add support for PostgreSQL as a backend.
• Improve deployment options (e.g., handling of TLS termination with OpenShift).

8. Performance and Scalability

• Measure and document current performance and throughput (esp. under high concurrency and with large repos).
• Enhance where necessary, especially for use-cases involving many mirrored repositories.

9. Project Maintenance and Governance

• Appoint and onboard additional maintainers (@grovesy and others).
• Improve maintainability to reduce friction from company-specific changes (e.g., authentication).
• Keep up-to-date with dependency versions and reduce divergence from upstream/main.

---

Suggested Action Items

Action List for Next Community Meeting

• [@kriswest] Collate and circulate this consolidated roadmap for comment ahead of next meeting.
• [@jescalada], [@andypols], [@re-vlad], [@dcoric] – Review and propose consensus on event hook system priorities and design.
• [@jescalada], [@dcoric], [@06kellyjac], [@goldensyntax] – Draft new/updated issues for plugin system refactor and extension.
• [@andypols], [@goldensyntax], [@fabiovincenzi] – Document accessibility and UI build issues, and schedule remediation.
• [@tabathad] – Provide update on OSTIF and security scan reports; coordinate with maintainers to address vulnerabilities.
• [@grovesy], [@mcleo-d] – Propose and initiate process for appointing additional maintainers.
• [@sam-holmes2], [@coopernetes] – Lead discussion on onboarding automation (users/projects) and fork management.
• [@jescalada] – Share performance/concurrency test results; propose any further testing needs.
• [@rajeevr-g], [@Andreybest] – Review TLS/OpenShift deployment issues and propose solutions or further tests.
• [All] – Identify potential overlap and dependencies between roadmap items to inform sequencing and prioritisation.
• [All] – Prepare to discuss relative prioritisation and sequencing at the next community meeting.

---

Community members are encouraged to edit this issue to add further detail, clarify requirements, or raise new items for consideration.

[kriswest]

NatWest Git Proxy Roadmap notes

1. New UI Accessibility review and remediation
2. Event-hooks - Notifications
   • Teams support (can't do easily here through web hooks...)
   • Email Notifications
   • Making sure all necessary fields are avialable in events to create good Notifications - existing PR had 2 of 8 fields we needed for a review notification card
3. Better account creation/onboarding support - admins should be able to create users and assign roles before login
4. Training requirements and admin approval (Contribution policy requirements)
   • Checks on user when raising a push - expose to reviewer/admins
   • Event hook for plugin support as well as or instead of configurable requirement.
5. Push annotations - attach notes to pushes as metadata (through UI/custom push annotations handling)
   • Will act as a base for raising PRs in future
6. Governing other activity on GitHub (etc.) through Git Proxy
   • Support for creating issues, comments, pull requests
   • Auditable logs for those activities
   • Optional review processes for them
7. Project onboarding
   • Handling requests for projects to be added to Git Proxy
   • Automating as much of the onboarding process as possible, with appropriate and configurable checks or review steps.
     • Plugin support?
   • Potentially allow a first pull and then push review to be created before an admin needs to be involved
     • Challenge is governing ingress - make it observable, governable etc. Include health warnings about ingress

[kriswest]

G-Research Roadmap priorities:

0. Postgres support
1. Extending the plugin system
   • Not as useful as they could be
   • First PR raised to enable plugin into phases
   • Mature pull request processing and extend plugins to pulls
     • POC for a supply chain scanning plugin
2. Security hardening
   • Achieve and maintain 0 CVEs
   • Resolve any OSTIF report outcomes
   • Resolve AI discovered flaws

[kriswest]

Citi

0. Appoint more maintainers
1. Finish creating an event-hook system and extend plugin system to support non-chain plugins
   • Evolve the event hook system and ensure that event handling doesn't affect subsequent events?
2. Check packages and CVEs - achieve 0 CVEs and maintain that
3. Better TLS support - want OpenShift to hand-off to the container

If testing shows this doesn't work:
4. Including HTML/JS etc. from the npm module - should be possible, but need to test - particularly need to test 2.2.0 release

[kriswest]

Qube

1. Finish building out the events system
   • Slack notifications
   • Email notifications
   • Plugin-style approach to using it
2. Extend Git Proxy to cover more of the opensource lifecycle
   • Raise issues and comments
   • Raise PRs - pre-approve PR content
   • Better handling for subsequent pushes - branch intelligence, close the old review /replace it with the new push based on which branch was being pushed.
3. Sync your fork
   • We use organisation-owned forks that need to be synced against the upstream repo periodically
   • We have a bot that creates a fork of the project using a custom git-proxy API
   • Elevate forking to a git-proxy feature?
4. Reduce how much our fork diverges from main - more types of plugin support

[kriswest]

Control Plane

1. Check packages and CVEs - achieve 0 CVEs and maintain that
   • Will help improve adoption
2. Plugin support (interesting but not important for us)
3. Performance measurement / enhance if needed
4. Other applications for git-proxy
   • Using it to apply rule to many mirrored repos

[kriswest]

Posted a consolidated summary of the roadmap discussion above