I still don't see any *new* problem that will arise because of this change.
Dani
From:
Aleksandar
Kurtakov <akurtako@xxxxxxxxxx>
To:
eclipse-pmc@xxxxxxxxxxx
Date:
04.10.2019
16:36
Subject:
[EXTERNAL]
Re: [eclipse-pmc] Gerrit submit strategies proposal
Sent
by: eclipse-pmc-bounces@xxxxxxxxxxx
On Fri, Oct 4, 2019 at 4:47 PM Thomas
Watson <tjwatson@xxxxxxxxxx>
wrote:
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
* generate reports https://download.eclipse.org/eclipse/downloads/drops4/I20191003-1800/buildlogs/reporeports/index.html
* 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
On Fri, Oct 4, 2019
at 3:59 PM Thomas Watson <tjwatson@xxxxxxxxxx>
wrote:
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
