hubcio commented on issue #3421: URL: https://github.com/apache/iggy/issues/3421#issuecomment-4709847346
couple more things, on your actual workflow questions (separate from the layout note above): branch model: i'm fine with either an integration branch or sequential prs straight into master, let me get the rest of the core team's read before we lock one in. two practical notes either way: a long-lived integration branch on apache/iggy needs write/force-push rights for the rebases, which a fork contributor doesn't have, and our pre-merge ci only triggers on prs into `master` (`branches: [master]`), so sub-prs into the branch wouldn't be gated automatically. direct-to-master incremental avoids both, and it's safe here since the crate is a leaf behind an opt-in binary so master stays green between slices. branch name's a non-issue, we can settle it if we end up going that route. @spetz @numinnex any opinion on this? pr size/order: no fixed loc cap from my side. just break it into independently-reviewable, ci-green slices and propose the boundaries, we'll iterate from there. naming: heads-up that `gateway` isn't in the allowed pr-title scopes yet (`.github/workflows/pr-title.yml`), so add it there in the foundation pr and title things `feat(gateway): ...`. for the binary, `iggy-kafka-gateway` fits the `iggy-*` convention (iggy-server, iggy-connectors). -- 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]
