I mistyped. I meant rebase if necessary. As far is not being a fan of "postfactum verification builds" what do you think our nightly builds we become if we have no verification builds done on the rebased commit?
There is huge difference between nightly builds and "postfactum verification builds"(aka gerrit jenkins builds). Nightly builds do things that gerrit verification builds can't achive:
* build all repos at once which uncovers issues which can't be found with single repo build
* publish resulting p2 repo
* rebuild natives
* run tests against already provisioned IDE instead of the different Tycho ways (IIRC there are still test suites that are not runnable using Tycho).
If your comment is more about nightly builds being broken due to rebases - I'm yet to see such case after years of using "Cherry Pick" (supposedly even riskier) with multiple other projects (CDT, Linux Tools, DLTK .....). I understand the theoretical chance of two API breaking changes in independent places (in the same repo) causing such a breakage but with our multi repository case we are already there as e.g. change in platform.runtime can causes pde.ui build failure today. A "postfactum verification build" will not help with this case at all.
Tom
----- Original message -----
From: Aleksandar Kurtakov <akurtako@xxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
To: eclipse-pmc@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [eclipse-pmc] Gerrit submit strategies proposal
Date: Fri, Oct 4, 2019 8:29 AM
I think merge if required policy is probably preferred. But can we still get a gerrit build run automatically when a merge commit is pushed to master? I'm not suggesting this as a way to block the gerrit submission. Instead it is a way to at least have a sanity build of the merge commit along with the other changes it merged with in master. Otherwise there is a slight risk of introducing a build break that goes unnoticed until the nightly build.
I'm not a fan of merge commits nor of postfactum verification builds. Why do you think merge if required is better than Rebase if Necessary? The later should prevent us from the possibility of broken code going into the repo.
Tom
----- Original message -----
From: "Daniel Megert" <daniel_megert@xxxxxxxxxx>
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
To: eclipse-pmc@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [eclipse-pmc] Gerrit submit strategies proposal
Date: Fri, Oct 4, 2019 4:36 AM
Looks like the tendency is +1.
The PMC discussion was deferred to next Tuesday, where we will make the final call.
Dani
From: Lars Vogel <lars.vogel@xxxxxxxxxxx>
To: eclipse-pmc@xxxxxxxxxxx
Date: 01.10.2019 13:01
Subject: [EXTERNAL] Re: [eclipse-pmc] Gerrit submit strategies proposal
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx
+1 I don't think that the rebased changes are reviewed again and
again, committers just have to wait a long time to get a merge window
and that is demotivating.
Now that our committer and contributor community activity has hugely
increased, we should remove that demotivating approach.
On Tue, Oct 1, 2019 at 12:40 PM Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:
>
> We are seeing an increating contributions and our gerrit verification jobs start to suffer due to our usage of "Fast forward only" strategy. Reality though is that no one rebases his change multiple times and wait for gerrit again just because another commit went in, I've tried and in platform.ui I gave up on 3rd rebase and just pushed it right after rebase. But even this generated one more totally useless gerrit build.
> So my proposal is to change our strategy to "Rebase if Necessary" - I don't see any downside using it and multiple benefits - free a lot of time on our builders, reduce interruptions for contributors and so on.
> Let's discuss today on PMC call
>
> Strategies explained: https://gerrit-review.googlesource.com/Documentation/concept-changes.html#submit-strategies
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> _______________________________________________
> eclipse-pmc mailing list
> eclipse-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse-pmc
--
Eclipse Platform project co-lead
CEO vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc
--
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc
