Hi David,
I checked the PR, looks good! And I think the times set are adequate.
Best,
--
Josep Prat
Open Source Engineering Director, Aiven
josep.p...@aiven.io | +491715557497 | aiven.io
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa,
Hey folks, I wanted to revive this old thread.
I'd like to do the following:
* Change our stale workflow to start with the oldest PRs and move forward
* Enable closing of stale PRs (over 120 days)
Here's a patch with these changes:
https://github.com/apache/kafka/pull/17166
Docs for actions/stal
Thanks, David. I left a few comments in the PR.
-David
Le ven. 9 juin 2023 à 15:31, David Arthur
a écrit :
> Hey all, I just wanted to bump this one more time before I merge this PR
> (thanks for the review, Josep!). I'll merge it at the end of the day today
> unless anyone has more feedback.
>
Hey all, I just wanted to bump this one more time before I merge this PR
(thanks for the review, Josep!). I'll merge it at the end of the day today
unless anyone has more feedback.
Thanks!
David
On Wed, Jun 7, 2023 at 8:50 PM David Arthur wrote:
> I filed KAFKA-15073 for this. Here is a patch
>
I filed KAFKA-15073 for this. Here is a patch
https://github.com/apache/kafka/pull/13827. This simply adds a "stale"
label to PRs with no activity in the last 90 days. I figure that's a good
starting point.
As for developer workflow, the "stale" action is quite flexible in how it
finds candidate P
Thanks David!
———
Josep Prat
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
m: +491715557497
w: aiven.io
e: josep.p...@aiven.io
On Wed, Jun 7, 2023, 20:28 David Arthur
wrote:
> Hey all, I
Hey all, I started poking around at Github actions on my fork.
https://github.com/mumrah/kafka/actions
I'll post a PR if I get it working and we can discuss what kind of settings
we want (or if we want it all)
-David
On Tue, Jun 6, 2023 at 1:18 PM Chris Egerton
wrote:
> Hi Josep,
>
> Thanks f
Hi Josep,
Thanks for bringing this up! Will try to keep things brief.
I'm generally in favor of this initiative. A couple ideas that I really
liked: requiring a component label (producer, consumer, connect, streams,
etc.) before closing, and disabling auto-close (i.e., automatically tagging
PRs a
Hi Josep,
Thanks for looking into this. This is clearly one aspect where we need
to improve.
We had a similar initiative last year
(https://lists.apache.org/thread/66yj9m6tcyz8zqb3lqlbnr386bqwsopt) and
we closed many PRs. Unfortunately we did not follow up with a process
or automation and we are
Hi Devs,
I would say we can split the problem in 2.
Waiting for Author feedback:
We could have a bot that would ping authors for the cases where we have PRs
that are stalled and have either:
- Merge conflict
- Unaddressed reviews
Waiting for reviewers:
For the PRs where we have no reviewers and t
Hi Nikolay,
With a bot it will be complicated to determine what to do when the PR
author is waiting for a reviewer. If a person goes over them, can check if
they are waiting for reviews and tag the PR accordingly and maybe ping a
maintainer.
If you look at my last email I described a flow (but AFA
Hello.
What is actions of contributor if no feedback given? [1], [2]
[1] https://github.com/apache/kafka/pull/13278
[2] https://github.com/apache/kafka/pull/13247
> 2 июня 2023 г., в 23:38, David Arthur написал(а):
>
> I think this is a great idea. If we don’t want the auto-close
> functional
I think this is a great idea. If we don’t want the auto-close
functionality, we can set it to -1
I realize this isn’t a vote, but I’m +1 on this
-David
On Fri, Jun 2, 2023 at 15:34 Colin McCabe wrote:
> That should read "30 days without activity"
>
> (I am assuming we have the ability to deter
That should read "30 days without activity"
(I am assuming we have the ability to determine when a PR was last updated on
GH)
best,
Colin
On Fri, Jun 2, 2023, at 12:32, Colin McCabe wrote:
> Hi all,
>
> Looking at GitHub, I have a bunch of Kafka PRs of my own that I've
> allowed to become stal
Hi all,
Looking at GitHub, I have a bunch of Kafka PRs of my own that I've allowed to
become stale, and I guess are pushing up these numbers! Overall I support the
goal of putting a time limit on PRs, just so that we can focus our review
bandwidth.
It may be best to start with a simple approac
Hi all,
I want to say that in my experience, I always felt better as a contributor
when a person told me something than when a bot did. That being said, I'm
not against bots, and I think they might be a great solution once we have a
manageable number of open PRs.
Another great question that addin
Hi Josep,
Thanks for bringing this up. I agree that we should clean it up. I think
that we should set up an automatic process to flag and then to close stale
pull requests. For instance, we could use a github action [1] for this. I
imagine that we could configure it to mark a pull request as stale
This is worthwhile, but can we use a bot for this? Many other projects do
so already.
Ismael
On Thu, Jun 1, 2023 at 9:24 AM Josep Prat
wrote:
> Hi Kafka devs,
>
> Seeing that we have over a 1000 PRs and that we want to try to keep the
> number low. I was thinking if it would make sense to go th
Hey Josep,
2-3weeks is pretty optimistic, but anything over a year can probably be
closed. If there's no response.
If they don't or we can't get any answer, we could close the
> PRs after 2 to 3 weeks.
Regular contributors can't label their own PRs though - it requires a
committer/collaborator t
Hi Josep,
Sounds like an important task for the community & project.
I would be happy to help in reaching out to the PR authors.
Thanks,
Kirk
> On Jun 1, 2023, at 9:24 AM, Josep Prat wrote:
>
> Hi Kafka devs,
>
> Seeing that we have over a 1000 PRs and that we want to try to keep the
> numbe
Hi Kafka devs,
Seeing that we have over a 1000 PRs and that we want to try to keep the
number low. I was thinking if it would make sense to go through the oldest
PRs and ping the authors to see if they want/can to go back to them and
finish them. If they don't or we can't get any answer, we could
21 matches
Mail list logo
