[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] GerritForge's JGit E2E tests with Gerrit in 2022
|
Hi Thomas,
Thanks for the feedback, see my comments inline.
> On 18 Jan 2022, at 19:01, Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
>
> On 18.01.22 16:37 , Luca Milanesio wrote:
>> Dear Gerrit and JGit developers’ community,
>> I would like to share with you the GerritForge’s plans for adding more E2E tests to JGit changes in 2022 [1].
>> Opinions, suggestions, objects, any sort of feedback is more than welcome :-)
>> Luca.
>> [1] https://gitenterprise.me/2022/01/18/new-year-new-jgit-contributions-coming/
>
> Somehow it seems to me that this proposed dev branch would become a
> de-facto fork. The writeup mentions this danger already.
That’s exactly what we are NOT aiming to: the ‘dev’ branch should be more a “fast lane” for faster verifications and merge, not a slowdown for incoming changes.
Also, none of the changes on the ‘dev’ branch will be merged into ‘master’ until it will get +2 by any maintainers, so it won’t be a risk for the JGit project’s master branch.
Should any of the changes on the ‘dev’ branch be vetoed, then we’ll revert it on the ‘dev’ branch also, for preventing the two branches to diverge.
> 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.
Of course, the *hope* may not materialise in the future, despite the potential meaningful contributions made on ‘dev’ but never merged on ‘master’.
Correct me if I am wrong, but un-merged changes won’t count for being promoted as maintainer.
> And now those should become some kind of
> gatekeeper for merging to master, when dev moves much faster?
Not really, we (GerritForge) aim to respect that workflow, but it won’t be required at all for any other contributions of course.
We are not maintainers of the JGit project, we just want to help pushing it forward faster.
>
> On top of that, I for one am working on JGit for fun in my free time.
> Don't expect me to keep up as a gatekeeper.
Sure, agreed. We won’t expect anyone to respect the Gerrit E2E validation.
Nevertheless *we will* respect it and guarantee that all changes we contribute make sense and don’t break things, validating it E2E with Gerrit.
>
> 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 :-(
>
> 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*.
Thanks again for your views.
>
> Cheers,
>
> Thomas
>
> _______________________________________________
> jgit-dev mailing list
> jgit-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jgit-dev
