[DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[David Arthur <mu...@gmail.com>]

Greetings, Kafka community!

At long last, the GitHub Merge Queue is upon us. This is a feature that
many of us have wanted for quite a while. After many months of discussion,
the excellent ASF Infra team has delivered!

Since this is quite a significant change, I have written up the details as
a KIP.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue

Please let me know what you think.

-- 
David Arthur

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[Ismael Juma <me...@ismaeljuma.com>]

Hi David,

Setting the repo config to always be PR title & body would be good as it's
a lot more predictable (most PRs have more than one commit by the end of
the PR review, but there are exceptions and it's harder for a committer to
update the commit message in such cases).

The reviewers verification makes sense. It would also be good to do
something about the "Committer Checklist" bit - it would be annoying to
have that in every commit message. We can either remove it from the
template (if we think it doesn't add value), automatically remove it during
the merge queue job or have a status check for it (along with the reviewers
bit).

Ismael

On Tue, Feb 4, 2025 at 6:55 AM David Arthur <mu...@gmail.com> wrote:

> Ismael, thanks for taking a look!
>
> We would need to alter the default commit message setting for the
> repository. The default (which we currently use) is PR title + PR body if
> there are multiple commits, or the commit subject and body if it's a single
> commit PR. We can change this to always be the PR title and PR body.
>
> Additionally, we can add a status check that validates that the PR body has
> the expected "Reviewers" field before merging. It might also be possible to
> automatically set that field.
>
> I have a feeling it might be possible to alter the commit message in the
> merge queue job, but that will take some experimentation.
>
> -David A
>
> On Tue, Feb 4, 2025 at 5:09 AM Ismael Juma <me...@ismaeljuma.com> wrote:
>
> > This looks good to me.
> >
> > My only comment is that merge queues have a weird limitation: you cannot
> > edit the commit message (unlike the traditional flow). I worry that this
> > will result in lower quality commit messages. Is there a way to configure
> > where the commit message comes from (PR title/description versus
> > aggregating all the commit messages in the PR)?
> >
> > Ismael
> >
> > On Mon, Feb 3, 2025, 8:02 AM David Arthur <mu...@gmail.com> wrote:
> >
> > > Happy Monday, all!
> > >
> > > I'd like to close out this discussion at some point this week, so I
> > wanted
> > > to bump this up once before moving to a vote.
> > >
> > > Did anyone have other feedback or concerns about moving towards the
> > GitHub
> > > Merge Queue?
> > >
> > > Thanks!
> > > David A
> > >
> > > On Thu, Jan 30, 2025 at 11:11 AM David Arthur <mu...@gmail.com>
> wrote:
> > >
> > > > Uchechi,
> > > >
> > > > While the build queue can run the builds concurrently, each build is
> > > > cumulative.
> > > >
> > > > For example, A, B, and C are added to the queue and A causes a
> problem
> > > for
> > > > C.
> > > >
> > > > Merge Queue: A, B, C
> > > >
> > > > Suppose we have concurrent builds and batching turned on. We might
> end
> > up
> > > > with two builds for these three PRs:
> > > >
> > > > Build 1: trunk + A
> > > > Build 2: trunk + A + B + C
> > > >
> > > > Each build is going to be cumulative. The point of the concurrency is
> > so
> > > > we don't have to wait for an in-progress build to finish before we
> > start
> > > > validating new PRs from the queue. In this case, build 2 would fail
> and
> > > PRs
> > > > B and C would get kicked back to the authors.
> > > >
> > > > As you can see, the batching and concurrency can complicate matters a
> > bit
> > > > which is why I suggest we start with no batching or concurrency.
> > > >
> > > > Hope this helps!
> > > > David A
> > > >
> > > > On Wed, Jan 29, 2025 at 2:34 AM Ukpa Uchechi <ukpauchechi1@gmail.com
> >
> > > > wrote:
> > > >
> > > >> Hi David,
> > > >>
> > > >> Thanks for this and for your work improving the Kafka CI.
> > > >>
> > > >> I have a question:
> > > >>
> > > >> A problem was mentioned about two PRs acting against each other when
> > > >> there’s no delay and being merged concurrently. Wouldn’t this still
> > > happen
> > > >> in the queue with concurrent merging as well?
> > > >> Best Regards,
> > > >> Uchechi.
> > > >>
> > > >> On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com>
> wrote:
> > > >>
> > > >> > Greetings, Kafka community!
> > > >> >
> > > >> > At long last, the GitHub Merge Queue is upon us. This is a feature
> > > that
> > > >> > many of us have wanted for quite a while. After many months of
> > > >> discussion,
> > > >> > the excellent ASF Infra team has delivered!
> > > >> >
> > > >> > Since this is quite a significant change, I have written up the
> > > details
> > > >> as
> > > >> > a KIP.
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> > > >> >
> > > >> > Please let me know what you think.
> > > >> >
> > > >> > --
> > > >> > David Arthur
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > David Arthur
> > > >
> > >
> > >
> > > --
> > > David Arthur
> > >
> >
>
>
> --
> David Arthur
>

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[David Arthur <mu...@gmail.com>]

Ismael, thanks for taking a look!

We would need to alter the default commit message setting for the
repository. The default (which we currently use) is PR title + PR body if
there are multiple commits, or the commit subject and body if it's a single
commit PR. We can change this to always be the PR title and PR body.

Additionally, we can add a status check that validates that the PR body has
the expected "Reviewers" field before merging. It might also be possible to
automatically set that field.

I have a feeling it might be possible to alter the commit message in the
merge queue job, but that will take some experimentation.

-David A

On Tue, Feb 4, 2025 at 5:09 AM Ismael Juma <me...@ismaeljuma.com> wrote:

> This looks good to me.
>
> My only comment is that merge queues have a weird limitation: you cannot
> edit the commit message (unlike the traditional flow). I worry that this
> will result in lower quality commit messages. Is there a way to configure
> where the commit message comes from (PR title/description versus
> aggregating all the commit messages in the PR)?
>
> Ismael
>
> On Mon, Feb 3, 2025, 8:02 AM David Arthur <mu...@gmail.com> wrote:
>
> > Happy Monday, all!
> >
> > I'd like to close out this discussion at some point this week, so I
> wanted
> > to bump this up once before moving to a vote.
> >
> > Did anyone have other feedback or concerns about moving towards the
> GitHub
> > Merge Queue?
> >
> > Thanks!
> > David A
> >
> > On Thu, Jan 30, 2025 at 11:11 AM David Arthur <mu...@gmail.com> wrote:
> >
> > > Uchechi,
> > >
> > > While the build queue can run the builds concurrently, each build is
> > > cumulative.
> > >
> > > For example, A, B, and C are added to the queue and A causes a problem
> > for
> > > C.
> > >
> > > Merge Queue: A, B, C
> > >
> > > Suppose we have concurrent builds and batching turned on. We might end
> up
> > > with two builds for these three PRs:
> > >
> > > Build 1: trunk + A
> > > Build 2: trunk + A + B + C
> > >
> > > Each build is going to be cumulative. The point of the concurrency is
> so
> > > we don't have to wait for an in-progress build to finish before we
> start
> > > validating new PRs from the queue. In this case, build 2 would fail and
> > PRs
> > > B and C would get kicked back to the authors.
> > >
> > > As you can see, the batching and concurrency can complicate matters a
> bit
> > > which is why I suggest we start with no batching or concurrency.
> > >
> > > Hope this helps!
> > > David A
> > >
> > > On Wed, Jan 29, 2025 at 2:34 AM Ukpa Uchechi <uk...@gmail.com>
> > > wrote:
> > >
> > >> Hi David,
> > >>
> > >> Thanks for this and for your work improving the Kafka CI.
> > >>
> > >> I have a question:
> > >>
> > >> A problem was mentioned about two PRs acting against each other when
> > >> there’s no delay and being merged concurrently. Wouldn’t this still
> > happen
> > >> in the queue with concurrent merging as well?
> > >> Best Regards,
> > >> Uchechi.
> > >>
> > >> On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
> > >>
> > >> > Greetings, Kafka community!
> > >> >
> > >> > At long last, the GitHub Merge Queue is upon us. This is a feature
> > that
> > >> > many of us have wanted for quite a while. After many months of
> > >> discussion,
> > >> > the excellent ASF Infra team has delivered!
> > >> >
> > >> > Since this is quite a significant change, I have written up the
> > details
> > >> as
> > >> > a KIP.
> > >> >
> > >> >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> > >> >
> > >> > Please let me know what you think.
> > >> >
> > >> > --
> > >> > David Arthur
> > >> >
> > >>
> > >
> > >
> > > --
> > > David Arthur
> > >
> >
> >
> > --
> > David Arthur
> >
>


-- 
David Arthur

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[Ismael Juma <me...@ismaeljuma.com>]

This looks good to me.

My only comment is that merge queues have a weird limitation: you cannot
edit the commit message (unlike the traditional flow). I worry that this
will result in lower quality commit messages. Is there a way to configure
where the commit message comes from (PR title/description versus
aggregating all the commit messages in the PR)?

Ismael

On Mon, Feb 3, 2025, 8:02 AM David Arthur <mu...@gmail.com> wrote:

> Happy Monday, all!
>
> I'd like to close out this discussion at some point this week, so I wanted
> to bump this up once before moving to a vote.
>
> Did anyone have other feedback or concerns about moving towards the GitHub
> Merge Queue?
>
> Thanks!
> David A
>
> On Thu, Jan 30, 2025 at 11:11 AM David Arthur <mu...@gmail.com> wrote:
>
> > Uchechi,
> >
> > While the build queue can run the builds concurrently, each build is
> > cumulative.
> >
> > For example, A, B, and C are added to the queue and A causes a problem
> for
> > C.
> >
> > Merge Queue: A, B, C
> >
> > Suppose we have concurrent builds and batching turned on. We might end up
> > with two builds for these three PRs:
> >
> > Build 1: trunk + A
> > Build 2: trunk + A + B + C
> >
> > Each build is going to be cumulative. The point of the concurrency is so
> > we don't have to wait for an in-progress build to finish before we start
> > validating new PRs from the queue. In this case, build 2 would fail and
> PRs
> > B and C would get kicked back to the authors.
> >
> > As you can see, the batching and concurrency can complicate matters a bit
> > which is why I suggest we start with no batching or concurrency.
> >
> > Hope this helps!
> > David A
> >
> > On Wed, Jan 29, 2025 at 2:34 AM Ukpa Uchechi <uk...@gmail.com>
> > wrote:
> >
> >> Hi David,
> >>
> >> Thanks for this and for your work improving the Kafka CI.
> >>
> >> I have a question:
> >>
> >> A problem was mentioned about two PRs acting against each other when
> >> there’s no delay and being merged concurrently. Wouldn’t this still
> happen
> >> in the queue with concurrent merging as well?
> >> Best Regards,
> >> Uchechi.
> >>
> >> On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
> >>
> >> > Greetings, Kafka community!
> >> >
> >> > At long last, the GitHub Merge Queue is upon us. This is a feature
> that
> >> > many of us have wanted for quite a while. After many months of
> >> discussion,
> >> > the excellent ASF Infra team has delivered!
> >> >
> >> > Since this is quite a significant change, I have written up the
> details
> >> as
> >> > a KIP.
> >> >
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> >> >
> >> > Please let me know what you think.
> >> >
> >> > --
> >> > David Arthur
> >> >
> >>
> >
> >
> > --
> > David Arthur
> >
>
>
> --
> David Arthur
>

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[David Arthur <mu...@gmail.com>]

Happy Monday, all!

I'd like to close out this discussion at some point this week, so I wanted
to bump this up once before moving to a vote.

Did anyone have other feedback or concerns about moving towards the GitHub
Merge Queue?

Thanks!
David A

On Thu, Jan 30, 2025 at 11:11 AM David Arthur <mu...@gmail.com> wrote:

> Uchechi,
>
> While the build queue can run the builds concurrently, each build is
> cumulative.
>
> For example, A, B, and C are added to the queue and A causes a problem for
> C.
>
> Merge Queue: A, B, C
>
> Suppose we have concurrent builds and batching turned on. We might end up
> with two builds for these three PRs:
>
> Build 1: trunk + A
> Build 2: trunk + A + B + C
>
> Each build is going to be cumulative. The point of the concurrency is so
> we don't have to wait for an in-progress build to finish before we start
> validating new PRs from the queue. In this case, build 2 would fail and PRs
> B and C would get kicked back to the authors.
>
> As you can see, the batching and concurrency can complicate matters a bit
> which is why I suggest we start with no batching or concurrency.
>
> Hope this helps!
> David A
>
> On Wed, Jan 29, 2025 at 2:34 AM Ukpa Uchechi <uk...@gmail.com>
> wrote:
>
>> Hi David,
>>
>> Thanks for this and for your work improving the Kafka CI.
>>
>> I have a question:
>>
>> A problem was mentioned about two PRs acting against each other when
>> there’s no delay and being merged concurrently. Wouldn’t this still happen
>> in the queue with concurrent merging as well?
>> Best Regards,
>> Uchechi.
>>
>> On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
>>
>> > Greetings, Kafka community!
>> >
>> > At long last, the GitHub Merge Queue is upon us. This is a feature that
>> > many of us have wanted for quite a while. After many months of
>> discussion,
>> > the excellent ASF Infra team has delivered!
>> >
>> > Since this is quite a significant change, I have written up the details
>> as
>> > a KIP.
>> >
>> >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
>> >
>> > Please let me know what you think.
>> >
>> > --
>> > David Arthur
>> >
>>
>
>
> --
> David Arthur
>


-- 
David Arthur

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[David Arthur <mu...@gmail.com>]

Uchechi,

While the build queue can run the builds concurrently, each build is
cumulative.

For example, A, B, and C are added to the queue and A causes a problem for
C.

Merge Queue: A, B, C

Suppose we have concurrent builds and batching turned on. We might end up
with two builds for these three PRs:

Build 1: trunk + A
Build 2: trunk + A + B + C

Each build is going to be cumulative. The point of the concurrency is so we
don't have to wait for an in-progress build to finish before we start
validating new PRs from the queue. In this case, build 2 would fail and PRs
B and C would get kicked back to the authors.

As you can see, the batching and concurrency can complicate matters a bit
which is why I suggest we start with no batching or concurrency.

Hope this helps!
David A

On Wed, Jan 29, 2025 at 2:34 AM Ukpa Uchechi <uk...@gmail.com> wrote:

> Hi David,
>
> Thanks for this and for your work improving the Kafka CI.
>
> I have a question:
>
> A problem was mentioned about two PRs acting against each other when
> there’s no delay and being merged concurrently. Wouldn’t this still happen
> in the queue with concurrent merging as well?
> Best Regards,
> Uchechi.
>
> On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
>
> > Greetings, Kafka community!
> >
> > At long last, the GitHub Merge Queue is upon us. This is a feature that
> > many of us have wanted for quite a while. After many months of
> discussion,
> > the excellent ASF Infra team has delivered!
> >
> > Since this is quite a significant change, I have written up the details
> as
> > a KIP.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> >
> > Please let me know what you think.
> >
> > --
> > David Arthur
> >
>


-- 
David Arthur

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[Ukpa Uchechi <uk...@gmail.com>]

Hi David,

Thanks for this and for your work improving the Kafka CI.

I have a question:

A problem was mentioned about two PRs acting against each other when
there’s no delay and being merged concurrently. Wouldn’t this still happen
in the queue with concurrent merging as well?
Best Regards,
Uchechi.

On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:

> Greetings, Kafka community!
>
> At long last, the GitHub Merge Queue is upon us. This is a feature that
> many of us have wanted for quite a while. After many months of discussion,
> the excellent ASF Infra team has delivered!
>
> Since this is quite a significant change, I have written up the details as
> a KIP.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
>
> Please let me know what you think.
>
> --
> David Arthur
>

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[David Arthur <mu...@gmail.com>]

Chris,

1) The expectation today is that we have a green PR build before merging.
This is sometimes relaxed in light of flaky tests at the discretion of the
committer merging the PR. In general, we should expect a green build before
merging a PR. This KIP does not change that requirement.

2) I expect it's probably in the 10s of minutes for the unit test suite.
Adding the unit tests to the merge queue workflow is certainly something we
can consider after we've rolled it out. One thing to keep in mind is that
any flakiness in the merge queue workflow will be very disruptive. It will
essentially kick the PR back to the author and will need to be enqueued
again.

Christo,

The merge queue validation will be in addition to our usual PR testing
workflow. Think of it as an extra bit of validation that happens after the
committer clicks the green merge button. So the sequence of events would be:

* New PR opened
* Existing CI workflow is run, green build obtained
* Committer approval
* Committer clicks "Merge when ready"
* PR added to merge queue
* Additional checks as part of merge queue workflow
* PR is merged to trunk


Thanks!
-David A


On Fri, Jan 24, 2025 at 6:10 AM Christo Lolov <ch...@gmail.com>
wrote:

> Heya David,
>
> Thanks a lot for this!
>
> Building on top of Chris's questions - does including only a subset of the
> stages in the merge queue mean that while subsequent stages (i.e. tests)
> can run in parallel-ish across PRs they will contain trunk + set of PRs
> ahead of this one which passed the stage in the merge queue + this PR? Or
> am I misunderstanding the sequence of events?
>
> Best,
> Christo
>
> On Fri, 24 Jan 2025 at 04:20, Chris Egerton <fe...@gmail.com>
> wrote:
>
> > Hi David,
> >
> > Thanks for the KIP, and for your ongoing work to improve Kafka CI.
> >
> > Two small thoughts:
> >
> > 1) Today, there's a convention of waiting for a green (or at least
> > completed) CI build before merging PRs, which includes running the full
> > test suite. This can be relaxed on a case-by-case basis but it's
> generally
> > expected for most PRs.
> >
> > Since we won't be running the full test suite in the merge queue, would I
> > be correct in assuming that it is not a goal of this KIP to further relax
> > that convention?
> >
> > 2) Do you have an estimate on the expected build time if we add unit
> tests?
> > I'm wondering if it would be feasible to enable them in the merge queue.
> >
> > Cheers,
> >
> > Chris
> >
> > On Thu, Jan 23, 2025, 22:06 Ukpa Uchechi <uk...@gmail.com> wrote:
> >
> > > Hey David,
> > >
> > > Is the credentials for Confluent data center different from the one
> used
> > to
> > > access Apache Kafka jira?
> > >
> > > Best Regards.
> > >
> > > On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
> > >
> > > > Greetings, Kafka community!
> > > >
> > > > At long last, the GitHub Merge Queue is upon us. This is a feature
> that
> > > > many of us have wanted for quite a while. After many months of
> > > discussion,
> > > > the excellent ASF Infra team has delivered!
> > > >
> > > > Since this is quite a significant change, I have written up the
> details
> > > as
> > > > a KIP.
> > > >
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> > > >
> > > > Please let me know what you think.
> > > >
> > > > --
> > > > David Arthur
> > > >
> > >
> >
>


-- 
David Arthur

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[Christo Lolov <ch...@gmail.com>]

Heya David,

Thanks a lot for this!

Building on top of Chris's questions - does including only a subset of the
stages in the merge queue mean that while subsequent stages (i.e. tests)
can run in parallel-ish across PRs they will contain trunk + set of PRs
ahead of this one which passed the stage in the merge queue + this PR? Or
am I misunderstanding the sequence of events?

Best,
Christo

On Fri, 24 Jan 2025 at 04:20, Chris Egerton <fe...@gmail.com> wrote:

> Hi David,
>
> Thanks for the KIP, and for your ongoing work to improve Kafka CI.
>
> Two small thoughts:
>
> 1) Today, there's a convention of waiting for a green (or at least
> completed) CI build before merging PRs, which includes running the full
> test suite. This can be relaxed on a case-by-case basis but it's generally
> expected for most PRs.
>
> Since we won't be running the full test suite in the merge queue, would I
> be correct in assuming that it is not a goal of this KIP to further relax
> that convention?
>
> 2) Do you have an estimate on the expected build time if we add unit tests?
> I'm wondering if it would be feasible to enable them in the merge queue.
>
> Cheers,
>
> Chris
>
> On Thu, Jan 23, 2025, 22:06 Ukpa Uchechi <uk...@gmail.com> wrote:
>
> > Hey David,
> >
> > Is the credentials for Confluent data center different from the one used
> to
> > access Apache Kafka jira?
> >
> > Best Regards.
> >
> > On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
> >
> > > Greetings, Kafka community!
> > >
> > > At long last, the GitHub Merge Queue is upon us. This is a feature that
> > > many of us have wanted for quite a while. After many months of
> > discussion,
> > > the excellent ASF Infra team has delivered!
> > >
> > > Since this is quite a significant change, I have written up the details
> > as
> > > a KIP.
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> > >
> > > Please let me know what you think.
> > >
> > > --
> > > David Arthur
> > >
> >
>

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[Chris Egerton <fe...@gmail.com>]

Hi David,

Thanks for the KIP, and for your ongoing work to improve Kafka CI.

Two small thoughts:

1) Today, there's a convention of waiting for a green (or at least
completed) CI build before merging PRs, which includes running the full
test suite. This can be relaxed on a case-by-case basis but it's generally
expected for most PRs.

Since we won't be running the full test suite in the merge queue, would I
be correct in assuming that it is not a goal of this KIP to further relax
that convention?

2) Do you have an estimate on the expected build time if we add unit tests?
I'm wondering if it would be feasible to enable them in the merge queue.

Cheers,

Chris

On Thu, Jan 23, 2025, 22:06 Ukpa Uchechi <uk...@gmail.com> wrote:

> Hey David,
>
> Is the credentials for Confluent data center different from the one used to
> access Apache Kafka jira?
>
> Best Regards.
>
> On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:
>
> > Greetings, Kafka community!
> >
> > At long last, the GitHub Merge Queue is upon us. This is a feature that
> > many of us have wanted for quite a while. After many months of
> discussion,
> > the excellent ASF Infra team has delivered!
> >
> > Since this is quite a significant change, I have written up the details
> as
> > a KIP.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
> >
> > Please let me know what you think.
> >
> > --
> > David Arthur
> >
>

Re: [DISCUSS] KIP-1126: Serialize changes to Kafka with a build queue

[Ukpa Uchechi <uk...@gmail.com>]

Hey David,

Is the credentials for Confluent data center different from the one used to
access Apache Kafka jira?

Best Regards.

On Fri, 24 Jan 2025 at 03:35, David Arthur <mu...@gmail.com> wrote:

> Greetings, Kafka community!
>
> At long last, the GitHub Merge Queue is upon us. This is a feature that
> many of us have wanted for quite a while. After many months of discussion,
> the excellent ASF Infra team has delivered!
>
> Since this is quite a significant change, I have written up the details as
> a KIP.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1126%3A+Serialize+changes+to+Kafka+with+build+queue
>
> Please let me know what you think.
>
> --
> David Arthur
>