As soon as you create a branch like this, you’re setting up for a fork. Don’t have the branch and you won’t end up forking. As noted below, this dev branch doesn’t solve the problems you’re trying to address. Do you think it solves something that you can’t do with open changes on master?
If you replace ‘dev’ with ‘fetch a series of open changes on master’, then it is exactly what we already do with verification of chained changes on the Gerrit project.
Great! I’m totally on board with using open changes instead of a ‘dev’ branch.
The proposal
also does not address the main bottleneck: too few active reviewers
and committers in JGit.
Correct, not directly. The *hope* is that the JGit community will see the growing contributions and competence shown by the new contributors and, eventually, decide to promote more contributors as new maintainers.
The current pace of contributions and reviews, from what we see on our changes, is too slow, which would bring the potential “promotion to maintainers” to many months (or years?) in the future.
I don’t think all JGit changes suffer from slow reviews and the pace of contributions is up to the contributors. This also misses that future JGit committers (maintainers) can also speed their path to promotion through reviewing others’ changes. That would seem to provide the most value because it directly addresses the concern of review not happening fast enough. If you care about that problem generally for the JGit project, this is an obvious way to contribute.
Sure, we need more reviewers and maintainers, both are needed and required.
Glad to see we 3 at least agree on the problem. :-)
I think a better way to speed up things would be to on-board new
committers. (And officially retire inactive ones.) If things don't go
fast enough for GerritForge, see that it has active committers in JGit,
and develop on master.
So far, it did not go fast enough :-(
What’s GerritForge’s plan for getting more contributors as JGit committers then? Sounds like the prerequisites would be 1) Contribute more JGit changes that get merged and 2) Help get other JGit changes merged through good reviews.
See [2].
Thanks for the link. That at least sets up for changes which *could* get merged. As you noted above, actually getting them merged is key. Is there a strategy around that where you think you’ve solved past challenges that have led to changes staying open/abandoned?
Do you also intend to engage on other JGit change reviews? I think Matthias had shared a few series that needed review help.
As for "Gerrit edge releases": I think you can do that already. Gerrit
builds JGit in tree, as a submodule, right? So just bump the submodule
pointer to the commit hash you want and build.
Sure, that’s a good idea regardless: as I mentioned, testing E2E with Gerrit is *always a good thing to do*.
I’m all for more E2E testing with Gerrit. That part of this proposal is awesome (and is very similar to ideas Martin and I have discussed in the past). I’m strongly against (and this needs discussion on the Gerrit list) any workflow that allows for a path where Gerrit uses a ‘dev’ version of JGit (purposefully or accidentally).
In the workflow at [3], the Gerrit changes does not get merged but is simply a *verification point* that the JGit change doesn’t break Gerrit E2E.
Thanks for clarifying that. Is there something in place in that workflow that will block that Gerrit change from merging until the submodule points to a commit from master (or a stable branch)?
Thanks for your input, appreciated it.
Thanks for getting this discussion going and for looking to invest more in JGit. It’s very appreciated. |
