11:13 a.m.
Hi all!
I've noticed that we started to often have broken builds because of tests.
We merge PRs anyway. I understand that it's the fault of the committer and
the reviewer, but maybe it worth blocking the PR for merge if build failed?
Thanks you, Nick, for the link:
https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
I means we can enforce PR reviews and CI checks before a PR can be merged.
We have 17 projects, so maybe just start with base, server, and openshift,
as they move / break the most?
What do you think?
Dmitrii
1:47 p.m.
FYI, not merging the broken patches is the policy followed by most
Eclipse.org projects and overall, none of this project has complained from
a reduced productivity; on the contrary, catching and fixing issues
immediately on the right context has improved quality and reduced the
necessary amount of quick fix patches (which are actually quite time
consuming and stressful for their low added-value).
So I think if it works for Eclipse.org projects, it can work for JBoss
Tools.
Cheers,
Mickael
2:01 a.m.
I'm ok with that rule except for one case when the pr is done before the
version bump has been merged then the Jenkins build will fail because of
the baseline check so maybe we need to update the pr Jenkins build
Jeff
Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a écrit :
FYI, not merging the broken patches is the policy followed by most
Eclipse.org projects and overall, none of this project has complained from
a reduced productivity; on the contrary, catching and fixing issues
immediately on the right context has improved quality and reduced the
necessary amount of quick fix patches (which are actually quite time
consuming and stressful for their low added-value).
So I think if it works for Eclipse.org projects, it can work for JBoss
Tools.
Cheers,
Mickael
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
3:17 a.m.
Jeff, for this purpose we can think of some special comment for such PRs,
that would allow to merge them (like *testPR* for a new build). As far as i
know it's possible.
On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com>
wrote:
I'm ok with that rule except for one case when the pr is done
before the
version bump has been merged then the Jenkins build will fail because of
the baseline check so maybe we need to update the pr Jenkins build
Jeff
Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a écrit :
> FYI, not merging the broken patches is the policy followed by most
> Eclipse.org projects and overall, none of this project has complained from
> a reduced productivity; on the contrary, catching and fixing issues
> immediately on the right context has improved quality and reduced the
> necessary amount of quick fix patches (which are actually quite time
> consuming and stressful for their low added-value).
> So I think if it works for Eclipse.org projects, it can work for JBoss
> Tools.
>
> Cheers,
> Mickael
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
3:36 a.m.
I agree in the principle. But for the approach to be successfull we need
our new new jenkins to be rocksolid which it isnt for now. Our EGit
tests fail randomly on it while they pass on the old jenkins.
Am 10.05.17 um 10:17 schrieb Dmitrii Bocharov:
Jeff, for this purpose we can think of some special comment for such
PRs, that would allow to merge them (like /testPR/ for a new build).
As far as i know it's possible.
On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury
<jmaury(a)redhat.com <mailto:jmaury@redhat.com>> wrote:
I'm ok with that rule except for one case when the pr is done
before the version bump has been merged then the Jenkins build
will fail because of the baseline check so maybe we need to update
the pr Jenkins build
Jeff
Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com
<mailto:mistria@redhat.com>> a écrit :
FYI, not merging the broken patches is the policy followed by
most Eclipse.org projects and overall, none of this project
has complained from a reduced productivity; on the contrary,
catching and fixing issues immediately on the right context
has improved quality and reduced the necessary amount of quick
fix patches (which are actually quite time consuming and
stressful for their low added-value).
So I think if it works for Eclipse.org projects, it can work
for JBoss Tools.
Cheers,
Mickael
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
<mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
<https://lists.jboss.org/mailman/listinfo/jbosstools-dev>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
3:41 a.m.
Last time I sent PR to openshift repo I had to be really patient, because
the build was failing on "java.io.IOException: Could not delete file
/mnt/hudson_workspace/workspace/jbosstools-openshift-Pull-Request/tests/org.jboss.tools.openshift.egit.test/target/work/data/Project-1494366069560".
I had to run the PR check job ~5 times for it to finally pass.
On Wed, May 10, 2017 at 10:38 AM Andre Dietisheim <adietish(a)redhat.com>
wrote:
I agree in the principle. But for the approach to be successfull we
need
our new new jenkins to be rocksolid which it isnt for now. Our EGit tests
fail randomly on it while they pass on the old jenkins.
Am 10.05.17 um 10:17 schrieb Dmitrii Bocharov:
Jeff, for this purpose we can think of some special comment for such PRs,
that would allow to merge them (like *testPR* for a new build). As far as
i know it's possible.
On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com>
wrote:
> I'm ok with that rule except for one case when the pr is done before the
> version bump has been merged then the Jenkins build will fail because of
> the baseline check so maybe we need to update the pr Jenkins build
>
> Jeff
>
> Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a écrit :
>
>> FYI, not merging the broken patches is the policy followed by most
>> Eclipse.org projects and overall, none of this project has complained from
>> a reduced productivity; on the contrary, catching and fixing issues
>> immediately on the right context has improved quality and reduced the
>> necessary amount of quick fix patches (which are actually quite time
>> consuming and stressful for their low added-value).
>> So I think if it works for Eclipse.org projects, it can work for JBoss
>> Tools.
>>
>> Cheers,
>> Mickael
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
_______________________________________________
jbosstools-dev mailing
listjbosstools-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
RADIM HOPP
RED HAT JBOSS DEVELOPER STUDIO QUALITY ASSURANCE
Red Hat Czech s.r.o. <https://www.redhat.com/>
rhopp(a)redhat.com IM: rhopp
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatway <https://twitter.com/redhatway> @redhatinc
<https://instagram.com/redhatinc> @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
3:44 a.m.
Radim, these are exactly the EGit failures that I was referring to. The
one you pasted is among the ones that occurr. But afaik the failures are
not consistent and they dont happen in the old jenkins.
Am 10.05.17 um 10:41 schrieb Radim Hopp:
Last time I sent PR to openshift repo I had to be really patient,
because the build was failing on "java.io.IOException: Could not
delete file
/mnt/hudson_workspace/workspace/jbosstools-openshift-Pull-Request/tests/org.jboss.tools.openshift.egit.test/target/work/data/Project-1494366069560".
I had to run the PR check job ~5 times for it to finally pass.
On Wed, May 10, 2017 at 10:38 AM Andre Dietisheim <adietish(a)redhat.com
<mailto:adietish@redhat.com>> wrote:
I agree in the principle. But for the approach to be successfull
we need our new new jenkins to be rocksolid which it isnt for now.
Our EGit tests fail randomly on it while they pass on the old jenkins.
Am 10.05.17 um 10:17 schrieb Dmitrii Bocharov:
> Jeff, for this purpose we can think of some special comment for
> such PRs, that would allow to merge them (like /testPR/ for a new
> build). As far as i know it's possible.
>
> On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury
> <jmaury(a)redhat.com <mailto:jmaury@redhat.com>> wrote:
>
> I'm ok with that rule except for one case when the pr is done
> before the version bump has been merged then the Jenkins
> build will fail because of the baseline check so maybe we
> need to update the pr Jenkins build
>
> Jeff
>
> Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com
> <mailto:mistria@redhat.com>> a écrit :
>
> FYI, not merging the broken patches is the policy
> followed by most Eclipse.org projects and overall, none
> of this project has complained from a reduced
> productivity; on the contrary, catching and fixing issues
> immediately on the right context has improved quality and
> reduced the necessary amount of quick fix patches (which
> are actually quite time consuming and stressful for their
> low added-value).
> So I think if it works for Eclipse.org projects, it can
> work for JBoss Tools.
>
> Cheers,
> Mickael
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> <mailto:jbosstools-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> <mailto:jbosstools-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org <mailto:jbosstools-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
RADIMHOPP
RED HAT JBOSS DEVELOPER STUDIO QUALITY ASSURANCE
Red HatCzech s.r.o. <https://www.redhat.com/>
rhopp(a)redhat.com <mailto:rhopp@redhat.com> IM:rhopp
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatway <https://twitter.com/redhatway>@redhatinc
<https://instagram.com/redhatinc>@redhatsnaps
<https://snapchat.com/add/redhatsnaps>
9:42 a.m.
randomly failing tests is an horror but they reveal real issues, often in
products, sometimes in tests or CI.
Changing CI is often a great way to discover all our "concurrency issues"
as everything is not running at the same pace.
For Fuse Tooling (and in my previous company), What i try to do when it
occurs instead of just relaunching the job is to report a JIRA issue.
it will help to gather more information, imagine how to add logs or
whatever to have more information when it will happen next. Each time it
occurs again, we can add a comment it helps to know what is the frequency
and what is the urgency to fix it. it is easier to include time for
investigation in sprint if we know how much we are loosing every sprint
(and how often a user might hit this issue).
At a comparison level, I saw a great keynote from OpenStack organization.
They also had this issue and they even created an automatic reporting with
automatic relaunch of jobs when it failed for known "random failures".
On Wed, May 10, 2017 at 10:44 AM, Andre Dietisheim <adietish(a)redhat.com>
wrote:
Radim, these are exactly the EGit failures that I was referring to.
The
one you pasted is among the ones that occurr. But afaik the failures are
not consistent and they dont happen in the old jenkins.
Am 10.05.17 um 10:41 schrieb Radim Hopp:
Last time I sent PR to openshift repo I had to be really patient, because
the build was failing on "java.io.IOException: Could not delete file
/mnt/hudson_workspace/workspace/jbosstools-openshift-Pull-Request/tests/
org.jboss.tools.openshift.egit.test/target/work/data/Project-1494366069560".
I had to run the PR check job ~5 times for it to finally pass.
On Wed, May 10, 2017 at 10:38 AM Andre Dietisheim <adietish(a)redhat.com>
wrote:
> I agree in the principle. But for the approach to be successfull we need
> our new new jenkins to be rocksolid which it isnt for now. Our EGit tests
> fail randomly on it while they pass on the old jenkins.
> Am 10.05.17 um 10:17 schrieb Dmitrii Bocharov:
>
> Jeff, for this purpose we can think of some special comment for such PRs,
> that would allow to merge them (like *testPR* for a new build). As far
> as i know it's possible.
>
> On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com>
> wrote:
>
>> I'm ok with that rule except for one case when the pr is done before the
>> version bump has been merged then the Jenkins build will fail because of
>> the baseline check so maybe we need to update the pr Jenkins build
>>
>> Jeff
>>
>> Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a
écrit :
>>
>>> FYI, not merging the broken patches is the policy followed by most
>>> Eclipse.org projects and overall, none of this project has complained from
>>> a reduced productivity; on the contrary, catching and fixing issues
>>> immediately on the right context has improved quality and reduced the
>>> necessary amount of quick fix patches (which are actually quite time
>>> consuming and stressful for their low added-value).
>>> So I think if it works for Eclipse.org projects, it can work for JBoss
>>> Tools.
>>>
>>> Cheers,
>>> Mickael
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>
>
>
> _______________________________________________
> jbosstools-dev mailing
listjbosstools-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
RADIM HOPP
RED HAT JBOSS DEVELOPER STUDIO QUALITY ASSURANCE
Red Hat Czech s.r.o. <https://www.redhat.com/>
rhopp(a)redhat.com IM: rhopp
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatway <https://twitter.com/redhatway> @redhatinc
<https://instagram.com/redhatinc> @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
AURÉLIEN PUPIER
SENIOR SOFTWARE ENGINEER, FUSE TOOLING
Red Hat France <https://www.redhat.com/>
apupier(a)redhat.com IM: apupier
<https://red.ht/sig>
9:30 a.m.
I would rather see these PRs fail specifically because the versions were
not correctly bumped.
Then the PR could be fixed to include the correct bump and resubmitted /
rebuilt.
Or if in the intervening time another commit happened which fixed the
versions, then the PR could be rebased and rebuilt.
But having them fail is* A GOOD THING* as it reminds people to build
locally before pushing the PR up to github. Doing so they'd see the
baseline check fail locally and could therefore apply the version bump
locally too.
For example (and not to pick on anyone - this is just the most recent
example I've seen) here's a commit that caused the build to break in both
4.4.x and master [1], which required 4 additional files [2] to be updated:
[1]
https://github.com/jbosstools/jbosstools-base/commit/3dafb287134414720de4...
[2]
https://github.com/jbosstools/jbosstools-base/commit/dbfad28ff809f99e8c3b...
You'll notice the PR [3] failed to build [4], too:
[3] https://github.com/jbosstools/jbosstools-base/pull/579
[4]
https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/jbosstoo...
"[ERROR] Failed to execute goal
org.eclipse.tycho.extras:tycho-p2-extras-plugin:1.0.0:compare-version-with-baselines
(default) on project org.jboss.tools.usage:
Only qualifier changed for (org.jboss.tools.usage/2.2.3.v20170505-1402).
Expected to have bigger x.y.z than what is available in baseline
(2.2.3.v20161213-1258)"
So these failures SHOULD be respected and SHOULD block pushing the PR into
the branch.
*+100 for Dmitri's suggestion of implementing Protected Branches and
Required Status Checks. *
We can furthermore do what Fuse Tools does and require that PRs be reviewed
before they can be merged, if we're ready to have that additional overhead
on every PR.
On Wed, May 10, 2017 at 3:17 AM, Dmitrii Bocharov <dbocharo(a)redhat.com>
wrote:
Jeff, for this purpose we can think of some special comment for such
PRs,
that would allow to merge them (like *testPR* for a new build). As far as
i know it's possible.
On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com>
wrote:
> I'm ok with that rule except for one case when the pr is done before the
> version bump has been merged then the Jenkins build will fail because of
> the baseline check so maybe we need to update the pr Jenkins build
>
> Jeff
>
> Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a écrit :
>
>> FYI, not merging the broken patches is the policy followed by most
>> Eclipse.org projects and overall, none of this project has complained from
>> a reduced productivity; on the contrary, catching and fixing issues
>> immediately on the right context has improved quality and reduced the
>> necessary amount of quick fix patches (which are actually quite time
>> consuming and stressful for their low added-value).
>> So I think if it works for Eclipse.org projects, it can work for JBoss
>> Tools.
>>
>> Cheers,
>> Mickael
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
12:56 p.m.
I would like to keep the version bump out of the pr because it will allow
us to cherry pick the pr in the maintenance branch
Le 10 mai 2017 16:31, "Nick Boldt" <nboldt(a)redhat.com> a écrit :
I would rather see these PRs fail specifically because the versions
were
not correctly bumped.
Then the PR could be fixed to include the correct bump and resubmitted /
rebuilt.
Or if in the intervening time another commit happened which fixed the
versions, then the PR could be rebased and rebuilt.
But having them fail is* A GOOD THING* as it reminds people to build
locally before pushing the PR up to github. Doing so they'd see the
baseline check fail locally and could therefore apply the version bump
locally too.
For example (and not to pick on anyone - this is just the most recent
example I've seen) here's a commit that caused the build to break in both
4.4.x and master [1], which required 4 additional files [2] to be updated:
[1] https://github.com/jbosstools/jbosstools-base/commit/
3dafb287134414720de46da20c7e2f210cd73aaf
[2] https://github.com/jbosstools/jbosstools-base/commit/
dbfad28ff809f99e8c3bf3d80b26cd06806d3b2f
You'll notice the PR [3] failed to build [4], too:
[3] https://github.com/jbosstools/jbosstools-base/pull/579
[4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.
com/job/jbosstools-base-Pull-Request/121/console
"[ERROR] Failed to execute goal org.eclipse.tycho.extras:
tycho-p2-extras-plugin:1.0.0:compare-version-with-baselines
(default) on project org.jboss.tools.usage:
Only qualifier changed for (org.jboss.tools.usage/2.2.3.v20170505-1402).
Expected to have bigger x.y.z than what is available in baseline
(2.2.3.v20161213-1258)"
So these failures SHOULD be respected and SHOULD block pushing the PR into
the branch.
*+100 for Dmitri's suggestion of implementing Protected Branches and
Required Status Checks. *
We can furthermore do what Fuse Tools does and require that PRs be
reviewed before they can be merged, if we're ready to have that additional
overhead on every PR.
On Wed, May 10, 2017 at 3:17 AM, Dmitrii Bocharov <dbocharo(a)redhat.com>
wrote:
> Jeff, for this purpose we can think of some special comment for such PRs,
> that would allow to merge them (like *testPR* for a new build). As far
> as i know it's possible.
>
> On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com>
> wrote:
>
>> I'm ok with that rule except for one case when the pr is done before the
>> version bump has been merged then the Jenkins build will fail because of
>> the baseline check so maybe we need to update the pr Jenkins build
>>
>> Jeff
>>
>> Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a
écrit :
>>
>>> FYI, not merging the broken patches is the policy followed by most
>>> Eclipse.org projects and overall, none of this project has complained from
>>> a reduced productivity; on the contrary, catching and fixing issues
>>> immediately on the right context has improved quality and reduced the
>>> necessary amount of quick fix patches (which are actually quite time
>>> consuming and stressful for their low added-value).
>>> So I think if it works for Eclipse.org projects, it can work for JBoss
>>> Tools.
>>>
>>> Cheers,
>>> Mickael
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
--
Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
12:10 p.m.
Better suggestion then:
* Make sure if your PR requires a version bump that the PR includes TWO
commits. One for the change, and one for the version bump. That way the
pair of commits can be built in the PR build and verify it works, AND when
cherry picking the commit across branches, you can pick only the change and
not the version-bump commit too.
So say we all?
Nick
On Wed, May 10, 2017 at 1:56 PM, Jean-Francois Maury <jmaury(a)redhat.com>
wrote:
I would like to keep the version bump out of the pr because it will
allow
us to cherry pick the pr in the maintenance branch
Le 10 mai 2017 16:31, "Nick Boldt" <nboldt(a)redhat.com> a écrit :
> I would rather see these PRs fail specifically because the versions were
> not correctly bumped.
> Then the PR could be fixed to include the correct bump and resubmitted /
> rebuilt.
> Or if in the intervening time another commit happened which fixed the
> versions, then the PR could be rebased and rebuilt.
>
> But having them fail is* A GOOD THING* as it reminds people to build
> locally before pushing the PR up to github. Doing so they'd see the
> baseline check fail locally and could therefore apply the version bump
> locally too.
>
> For example (and not to pick on anyone - this is just the most recent
> example I've seen) here's a commit that caused the build to break in both
> 4.4.x and master [1], which required 4 additional files [2] to be updated:
>
> [1] https://github.com/jbosstools/jbosstools-base/commit/3dafb28
> 7134414720de46da20c7e2f210cd73aaf
> [2] https://github.com/jbosstools/jbosstools-base/commit/dbfad28
> ff809f99e8c3bf3d80b26cd06806d3b2f
>
> You'll notice the PR [3] failed to build [4], too:
>
> [3] https://github.com/jbosstools/jbosstools-base/pull/579
> [4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com
> /job/jbosstools-base-Pull-Request/121/console
>
> "[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho
> -p2-extras-plugin:1.0.0:compare-version-with-baselines
> (default) on project org.jboss.tools.usage:
> Only qualifier changed for (org.jboss.tools.usage/2.2.3.v20170505-1402).
> Expected to have bigger x.y.z than what is available in baseline
> (2.2.3.v20161213-1258)"
>
> So these failures SHOULD be respected and SHOULD block pushing the PR
> into the branch.
>
> *+100 for Dmitri's suggestion of implementing Protected Branches and
> Required Status Checks. *
>
> We can furthermore do what Fuse Tools does and require that PRs be
> reviewed before they can be merged, if we're ready to have that additional
> overhead on every PR.
>
>
>
> On Wed, May 10, 2017 at 3:17 AM, Dmitrii Bocharov <dbocharo(a)redhat.com>
> wrote:
>
>> Jeff, for this purpose we can think of some special comment for such
>> PRs, that would allow to merge them (like *testPR* for a new build). As
>> far as i know it's possible.
>>
>> On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com>
>> wrote:
>>
>>> I'm ok with that rule except for one case when the pr is done before
>>> the version bump has been merged then the Jenkins build will fail because
>>> of the baseline check so maybe we need to update the pr Jenkins build
>>>
>>> Jeff
>>>
>>> Le 9 mai 2017 23:10, "Mickael Istria" <mistria(a)redhat.com> a
écrit :
>>>
>>>> FYI, not merging the broken patches is the policy followed by most
>>>> Eclipse.org projects and overall, none of this project has complained
from
>>>> a reduced productivity; on the contrary, catching and fixing issues
>>>> immediately on the right context has improved quality and reduced the
>>>> necessary amount of quick fix patches (which are actually quite time
>>>> consuming and stressful for their low added-value).
>>>> So I think if it works for Eclipse.org projects, it can work for JBoss
>>>> Tools.
>>>>
>>>> Cheers,
>>>> Mickael
>>>>
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
>
>
> --
>
> Nick Boldt
>
> Senior Software Engineer, RHCSA
>
> Productization Lead :: JBoss Tools & Dev Studio
>
> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> @ @redhatnews <https://twitter.com/redhatnews> Red Hat
> <https://www.facebook.com/RedHatInc>
>
--
Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
12:14 p.m.
Simple is beautiful. I fully agree
+1
On Thu, May 11, 2017 at 7:10 PM, Nick Boldt <nboldt(a)redhat.com> wrote:
Better suggestion then:
* Make sure if your PR requires a version bump that the PR includes TWO
commits. One for the change, and one for the version bump. That way the
pair of commits can be built in the PR build and verify it works, AND when
cherry picking the commit across branches, you can pick only the change and
not the version-bump commit too.
So say we all?
Nick
On Wed, May 10, 2017 at 1:56 PM, Jean-Francois Maury <jmaury(a)redhat.com>
wrote:
> I would like to keep the version bump out of the pr because it will allow
> us to cherry pick the pr in the maintenance branch
>
>
>
> Le 10 mai 2017 16:31, "Nick Boldt" <nboldt(a)redhat.com> a écrit :
>
>> I would rather see these PRs fail specifically because the versions were
>> not correctly bumped.
>> Then the PR could be fixed to include the correct bump and resubmitted /
>> rebuilt.
>> Or if in the intervening time another commit happened which fixed the
>> versions, then the PR could be rebased and rebuilt.
>>
>> But having them fail is* A GOOD THING* as it reminds people to build
>> locally before pushing the PR up to github. Doing so they'd see the
>> baseline check fail locally and could therefore apply the version bump
>> locally too.
>>
>> For example (and not to pick on anyone - this is just the most recent
>> example I've seen) here's a commit that caused the build to break in
both
>> 4.4.x and master [1], which required 4 additional files [2] to be updated:
>>
>> [1] https://github.com/jbosstools/jbosstools-base/commit/3dafb28
>> 7134414720de46da20c7e2f210cd73aaf
>> [2] https://github.com/jbosstools/jbosstools-base/commit/dbfad28
>> ff809f99e8c3bf3d80b26cd06806d3b2f
>>
>> You'll notice the PR [3] failed to build [4], too:
>>
>> [3] https://github.com/jbosstools/jbosstools-base/pull/579
>> [4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com
>> /job/jbosstools-base-Pull-Request/121/console
>>
>> "[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho
>> -p2-extras-plugin:1.0.0:compare-version-with-baselines
>> (default) on project org.jboss.tools.usage:
>> Only qualifier changed for (org.jboss.tools.usage/2.2.3.v20170505-1402).
>>
>> Expected to have bigger x.y.z than what is available in baseline
>> (2.2.3.v20161213-1258)"
>>
>> So these failures SHOULD be respected and SHOULD block pushing the PR
>> into the branch.
>>
>> *+100 for Dmitri's suggestion of implementing Protected Branches and
>> Required Status Checks. *
>>
>> We can furthermore do what Fuse Tools does and require that PRs be
>> reviewed before they can be merged, if we're ready to have that additional
>> overhead on every PR.
>>
>>
>>
>> On Wed, May 10, 2017 at 3:17 AM, Dmitrii Bocharov <dbocharo(a)redhat.com>
>> wrote:
>>
>>> Jeff, for this purpose we can think of some special comment for such
>>> PRs, that would allow to merge them (like *testPR* for a new build).
>>> As far as i know it's possible.
>>>
>>> On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <jmaury(a)redhat.com
>>> > wrote:
>>>
>>>> I'm ok with that rule except for one case when the pr is done before
>>>> the version bump has been merged then the Jenkins build will fail
because
>>>> of the baseline check so maybe we need to update the pr Jenkins build
>>>>
>>>> Jeff
>>>>
>>>> Le 9 mai 2017 23:10, "Mickael Istria"
<mistria(a)redhat.com> a écrit :
>>>>
>>>>> FYI, not merging the broken patches is the policy followed by most
>>>>> Eclipse.org projects and overall, none of this project has complained
from
>>>>> a reduced productivity; on the contrary, catching and fixing issues
>>>>> immediately on the right context has improved quality and reduced
the
>>>>> necessary amount of quick fix patches (which are actually quite time
>>>>> consuming and stressful for their low added-value).
>>>>> So I think if it works for Eclipse.org projects, it can work for
>>>>> JBoss Tools.
>>>>>
>>>>> Cheers,
>>>>> Mickael
>>>>>
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>
>>
>>
>> --
>>
>> Nick Boldt
>>
>> Senior Software Engineer, RHCSA
>>
>> Productization Lead :: JBoss Tools & Dev Studio
>>
>> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
>> <https://red.ht/sig>
>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>> @ @redhatnews <https://twitter.com/redhatnews> Red Hat
>> <https://www.facebook.com/RedHatInc>
>>
>
--
Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
--
JEFF MAURY
Red Hat
<https://www.redhat.com/>
jmaury(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs/> @redhatjobs
<https://instagram.com/redhatjobs>
12:23 p.m.
I've opened https://issues.jboss.org/browse/JBIDE-24439 to track this
request and gather SPECIFIC requests from project leads as to what projects
should be changed and how they should be protected.
Thanks,
Nick
On Thu, May 11, 2017 at 1:14 PM, Jean-Francois Maury <jmaury(a)redhat.com>
wrote:
Simple is beautiful. I fully agree
+1
On Thu, May 11, 2017 at 7:10 PM, Nick Boldt <nboldt(a)redhat.com> wrote:
> Better suggestion then:
>
> * Make sure if your PR requires a version bump that the PR includes TWO
> commits. One for the change, and one for the version bump. That way the
> pair of commits can be built in the PR build and verify it works, AND when
> cherry picking the commit across branches, you can pick only the change and
> not the version-bump commit too.
>
> So say we all?
>
> Nick
>
>
> On Wed, May 10, 2017 at 1:56 PM, Jean-Francois Maury <jmaury(a)redhat.com>
> wrote:
>
>> I would like to keep the version bump out of the pr because it will
>> allow us to cherry pick the pr in the maintenance branch
>>
>>
>>
>> Le 10 mai 2017 16:31, "Nick Boldt" <nboldt(a)redhat.com> a écrit :
>>
>>> I would rather see these PRs fail specifically because the versions
>>> were not correctly bumped.
>>> Then the PR could be fixed to include the correct bump and resubmitted
>>> / rebuilt.
>>> Or if in the intervening time another commit happened which fixed the
>>> versions, then the PR could be rebased and rebuilt.
>>>
>>> But having them fail is* A GOOD THING* as it reminds people to build
>>> locally before pushing the PR up to github. Doing so they'd see the
>>> baseline check fail locally and could therefore apply the version bump
>>> locally too.
>>>
>>> For example (and not to pick on anyone - this is just the most recent
>>> example I've seen) here's a commit that caused the build to break in
both
>>> 4.4.x and master [1], which required 4 additional files [2] to be updated:
>>>
>>> [1] https://github.com/jbosstools/jbosstools-base/commit/3dafb28
>>> 7134414720de46da20c7e2f210cd73aaf
>>> [2] https://github.com/jbosstools/jbosstools-base/commit/dbfad28
>>> ff809f99e8c3bf3d80b26cd06806d3b2f
>>>
>>> You'll notice the PR [3] failed to build [4], too:
>>>
>>> [3] https://github.com/jbosstools/jbosstools-base/pull/579
>>> [4] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com
>>> /job/jbosstools-base-Pull-Request/121/console
>>>
>>> "[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho
>>> -p2-extras-plugin:1.0.0:compare-version-with-baselines
>>> (default) on project org.jboss.tools.usage:
>>> Only qualifier changed for (org.jboss.tools.usage/2.2.3.v20170505-1402).
>>>
>>> Expected to have bigger x.y.z than what is available in baseline
>>> (2.2.3.v20161213-1258)"
>>>
>>> So these failures SHOULD be respected and SHOULD block pushing the PR
>>> into the branch.
>>>
>>> *+100 for Dmitri's suggestion of implementing Protected Branches and
>>> Required Status Checks. *
>>>
>>> We can furthermore do what Fuse Tools does and require that PRs be
>>> reviewed before they can be merged, if we're ready to have that
additional
>>> overhead on every PR.
>>>
>>>
>>>
>>> On Wed, May 10, 2017 at 3:17 AM, Dmitrii Bocharov
<dbocharo(a)redhat.com>
>>> wrote:
>>>
>>>> Jeff, for this purpose we can think of some special comment for such
>>>> PRs, that would allow to merge them (like *testPR* for a new build).
>>>> As far as i know it's possible.
>>>>
>>>> On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury <
>>>> jmaury(a)redhat.com> wrote:
>>>>
>>>>> I'm ok with that rule except for one case when the pr is done
before
>>>>> the version bump has been merged then the Jenkins build will fail
because
>>>>> of the baseline check so maybe we need to update the pr Jenkins
build
>>>>>
>>>>> Jeff
>>>>>
>>>>> Le 9 mai 2017 23:10, "Mickael Istria"
<mistria(a)redhat.com> a écrit :
>>>>>
>>>>>> FYI, not merging the broken patches is the policy followed by
most
>>>>>> Eclipse.org projects and overall, none of this project has
complained from
>>>>>> a reduced productivity; on the contrary, catching and fixing
issues
>>>>>> immediately on the right context has improved quality and reduced
the
>>>>>> necessary amount of quick fix patches (which are actually quite
time
>>>>>> consuming and stressful for their low added-value).
>>>>>> So I think if it works for Eclipse.org projects, it can work for
>>>>>> JBoss Tools.
>>>>>>
>>>>>> Cheers,
>>>>>> Mickael
>>>>>>
>>>>>> _______________________________________________
>>>>>> jbosstools-dev mailing list
>>>>>> jbosstools-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Nick Boldt
>>>
>>> Senior Software Engineer, RHCSA
>>>
>>> Productization Lead :: JBoss Tools & Dev Studio
>>>
>>> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
>>> <https://red.ht/sig>
>>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>> @ @redhatnews <https://twitter.com/redhatnews> Red Hat
>>> <https://www.facebook.com/RedHatInc>
>>>
>>
>
>
> --
>
> Nick Boldt
>
> Senior Software Engineer, RHCSA
>
> Productization Lead :: JBoss Tools & Dev Studio
>
> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> @ @redhatnews <https://twitter.com/redhatnews> Red Hat
> <https://www.facebook.com/RedHatInc>
>
--
JEFF MAURY
Red Hat
<https://www.redhat.com/>
jmaury(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
@redhatjobs <https://twitter.com/redhatjobs> redhatjobs
<https://www.facebook.com/redhatjobs/> @redhatjobs
<https://instagram.com/redhatjobs>
--
Nick Boldt
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat
<https://www.facebook.com/RedHatInc>
2852
days inactive
2854
days old
jbosstools-dev@lists.jboss.org
12 comments
7 participants
participants (7)
-
Andre Dietisheim -
Aurelien Pupier -
Dmitrii Bocharov -
Jean-Francois Maury -
Mickael Istria -
Nick Boldt -
Radim Hopp