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