You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Kirk True <ki...@kirktrue.pro> on 2023/04/28 00:14:13 UTC
[DISCUSS] Recommendations for managing long-running projects
Hi all,
A handful of engineers are collaborating on a fairly sizable project to improve the Java consumer client [1]. We are using as many ASF tools as possible for the work (wiki, Jira, mailing list, and Slack thus far).
There are yet two areas where we need recommendations:
1. Project management tools. What is the recommended tool for communicating project scheduling, milestones, etc.?
2. Shared code collaboration. Since none of the engineers on the project are committers, we can't collaborate by reviewing and merging our changes into trunk. Is there a recommended path to collaborate for non-committers?
Thanks,
Kirk
[1] https://cwiki.apache.org/confluence/display/KAFKA/Consumer+threading+refactor+project+overview
Re: [DISCUSS] Recommendations for managing long-running projects
Posted by Philip Nee <ph...@gmail.com>.
Hi Kirk and David,
Thanks for raising this, Kirk.
David, to your questions, as I'm also contributing to the project:
Do you expect the changes to come in incrementally, or as a few large
patches? We try to limit the PR size as much as possible, but sometimes it
is inevitably large...
We could be experimenting the fork-feature branch idea.
Thanks,
P
On Fri, Apr 28, 2023 at 6:50 AM David Arthur
<da...@confluent.io.invalid> wrote:
> Kirk,
> 1) I would check out the project management features built into GitHub,
> e.g., labels, milestones, and projects
>
> https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects
> .
>
> 2) Ultimately, the contributions will need to follow the normal PR
> workflow. A committer will have to review and approve the changes. For big
> changes, it's probably best to get more than one committer to approve. Do
> you expect the changes to come in incrementally, or as a few large patches?
> For major efforts in the past, we have taken the approach of using a
> non-trunk feature branch where we land and stabilize new code. The downside
> here is the effort involved in integrating new changes from upstream. If
> it's mostly greenfield work (i.e., new classes), this might not be a big
> problem. Another downside of this approach is the effort involved in
> reviewing a massive PR to trunk that is bringing in a large code base.
>
> Here's a possible workflow:
> * Create a feature branch on a fork
> * Non-committers can commit directly to this branch, or use a PR workflow
> using the feature branch as a base
> * Stabilize the feature branch
> * Break the changeset into a few sensible PRs for merging into trunk. This
> could be something like interfaces and configs first followed by
> implementation and tests.
>
>
> To answer this more directly
> > Is there a recommended path to collaborate for non-committers?
> The normal collaboration path for non-committers is to submit Pull Requests
> against trunk. Non-committers can review PRs, they just can't merge them
> or +1 them.
>
> HTH,
> David
>
> On Thu, Apr 27, 2023 at 8:15 PM Kirk True <ki...@kirktrue.pro> wrote:
>
> > Hi all,
> >
> > A handful of engineers are collaborating on a fairly sizable project to
> > improve the Java consumer client [1]. We are using as many ASF tools as
> > possible for the work (wiki, Jira, mailing list, and Slack thus far).
> >
> > There are yet two areas where we need recommendations:
> >
> > 1. Project management tools. What is the recommended tool for
> > communicating project scheduling, milestones, etc.?
> >
> > 2. Shared code collaboration. Since none of the engineers on the project
> > are committers, we can't collaborate by reviewing and merging our changes
> > into trunk. Is there a recommended path to collaborate for
> non-committers?
> >
> > Thanks,
> > Kirk
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Consumer+threading+refactor+project+overview
>
>
>
> --
> -David
>
Re: [DISCUSS] Recommendations for managing long-running projects
Posted by David Arthur <da...@confluent.io.INVALID>.
Kirk,
1) I would check out the project management features built into GitHub,
e.g., labels, milestones, and projects
https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects
.
2) Ultimately, the contributions will need to follow the normal PR
workflow. A committer will have to review and approve the changes. For big
changes, it's probably best to get more than one committer to approve. Do
you expect the changes to come in incrementally, or as a few large patches?
For major efforts in the past, we have taken the approach of using a
non-trunk feature branch where we land and stabilize new code. The downside
here is the effort involved in integrating new changes from upstream. If
it's mostly greenfield work (i.e., new classes), this might not be a big
problem. Another downside of this approach is the effort involved in
reviewing a massive PR to trunk that is bringing in a large code base.
Here's a possible workflow:
* Create a feature branch on a fork
* Non-committers can commit directly to this branch, or use a PR workflow
using the feature branch as a base
* Stabilize the feature branch
* Break the changeset into a few sensible PRs for merging into trunk. This
could be something like interfaces and configs first followed by
implementation and tests.
To answer this more directly
> Is there a recommended path to collaborate for non-committers?
The normal collaboration path for non-committers is to submit Pull Requests
against trunk. Non-committers can review PRs, they just can't merge them
or +1 them.
HTH,
David
On Thu, Apr 27, 2023 at 8:15 PM Kirk True <ki...@kirktrue.pro> wrote:
> Hi all,
>
> A handful of engineers are collaborating on a fairly sizable project to
> improve the Java consumer client [1]. We are using as many ASF tools as
> possible for the work (wiki, Jira, mailing list, and Slack thus far).
>
> There are yet two areas where we need recommendations:
>
> 1. Project management tools. What is the recommended tool for
> communicating project scheduling, milestones, etc.?
>
> 2. Shared code collaboration. Since none of the engineers on the project
> are committers, we can't collaborate by reviewing and merging our changes
> into trunk. Is there a recommended path to collaborate for non-committers?
>
> Thanks,
> Kirk
>
> [1]
> https://cwiki.apache.org/confluence/display/KAFKA/Consumer+threading+refactor+project+overview
--
-David