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?
What I’ve seen in the past is reluctance to merge changes because of lack of knowledge of the possible implications and fear of breaking stuff. I was hoping that more E2E testing with Gerrit (or other use-cases?) could help bringing more confidence.
Thomas/Matthias/others, does this match your understanding? Would more E2E testing help? Would something else help more?
P.S. Running Gatling E2E tests on Gerrit we actually found tons of JGit bugs and fixed them in the past :-) Remember the repo corruption during GC + concurrent receive-packs? All found and fixed during a Gerrit stabilisation phase when running Gatling tests.
Yes! Testing is great.
Do you also intend to engage on other JGit change reviews? I think Matthias had shared a few series that needed review help.
We are already and we’ll do more.
+1
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)?
@Luca did you miss this ^?
Thanks for the reminder: we could automatically add a -2 and a “[DO NOT MERGE]” prefix. I agree that we should never ever merge a submodule pointing to a non-merged change !!!
Thanks for your input, appreciated it.
Thanks for getting this discussion going and for looking to invest more in JGit. It’s very appreciated.
I was also thinking about proposing a “JGit hackathon” :-) We want to crack on multi-pack indexes and a hackathon would help making the momentum on that.
WDYT?
I’m interested. I don’t know what kind of pre-req work is needed to support multi-pack indexes and/or if there’s a clear design for how to support that in JGit. It’d be good to have a good understanding of those ahead of any hackathon (unless we can be sure sufficient folks with necessary inputs will be present).
Yes, definitely. We should have some brainstorming / design sessions beforehand, so that we start the hackathon already focused and with clear ideas.
Luca.
|
