ryerraguntla commented on issue #3421: URL: https://github.com/apache/iggy/issues/3421#issuecomment-4675165612
@spetz @hubcio @mmodzelewski @krishvishal @kparisa - I need your opinion and guidance on the below proposal. If it is acceptable, could one of you do the needful. ## Proposed integration branch for multi-PR Kafka gateway work Following up on #3421 — the Kafka gateway work is intentionally split across **multiple successive PRs** (foundation → Iggy bridge → additional APIs/behavior) like mentioned at https://github.com/apache/iggy/discussions/3253#discussioncomment-17181030 . Each slice should stay reviewable on its own, but the community should be able to see **cumulative progress** in one place before anything lands on `master`. ### Request Could a maintainer please: 1. **Create an integration branch** on `apache/iggy`, e.g. `iggy_gateway_for_kafka`, from current `master`. 2. **Confirm** that sub-PRs for this effort should target that branch (not `master`) until the feature set is complete. 3. **Confirm branch naming** — happy to use `iggy_gateway_for_kafka` or whatever fits project convention. ### Proposed workflow ``` master (stable) │ └── iggy_gateway_for_kafka ← integration branch (public, long-lived) │ ├── PR1: TCP listener, wire codec, version firewall, │ stub responses, tests, kafka-tool │ ├── PR2: … (next slice — TBD with maintainers) │ ├── PR3: … │ └── Final PR: iggy_gateway_for_kafka → master (when complete; then delete branch) ``` - Each sub-PR: **one purpose**, linked to **#3421**, with local checks per `CONTRIBUTING.md`. - After each merge, `iggy_gateway_for_kafka` advances so anyone can browse the full in-progress tree. - **Final PR** merges the integration branch into `master` once functionality and tests are in place. ### PR1 scope (ready / nearly ready) First sub-PR (~foundation from #3421): - `gateways/kafka/` — TCP listener, request decode, version firewall, stub responses (Produce, Fetch, ListOffsets, Metadata, ApiVersions, CreateTopics) - Version-aware error responses (not bare 2-byte stubs for scoped APIs) - `KAFKA_ADVERTISED_HOST` / broker advertisement validation - Regression tests (103 tests) + `kafka-message-gen` tool for wire fixtures - Docs: `SCOPE.md`, `TEST_SUITE.md`, `MANUAL_TESTING.md` Does **not** include Iggy backend bridge yet — that would be a follow-on PR on the same integration branch. ### Questions for maintainers 1. Is an **`apache/iggy` integration branch** acceptable for this feature, or do you prefer sequential PRs directly to `master`? 2. Preferred branch name — `iggy_gateway_for_kafka` or other? 3. Should **pre-merge CI** run on PRs targeting the integration branch? Today workflows appear limited to PRs into `master`; I can run full local checks on each sub-PR regardless. 4. Any guidance on **PR size/order** beyond CONTRIBUTING (e.g. <500 LOC for new contributors, high-risk protocol areas)? ### My setup - Working branch locally: `feat(gateways)/kafka_to_iggy_listener` - Fork: `ryerraguntla/iggy` - Once the integration branch exists, I'll open **PR1** as: `ryerraguntla:<branch>` → `apache/iggy:iggy_gateway_for_kafka` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
