On 07/09/2013 11:59 AM, Dennis Hübner wrote:
A lot of failed builds were caused by missing (suddenly
deleted/disappeared) artifacts not by incoming model changes.
So autovalidation by Jenkins will probably prevent maintainers to
submit a patch which fixes, but depends on the broken master state.
So IMHO gerrit would not eliminate the problem in the whole, but can
probably make the maintenance not that easy
That's right, but the value of code review is mainly in educating
(mid-term/long-term benefit). Currently, it seems like (some) people
push stuff to aggregator without understanding that this needs to be
stable content. Having a code review phase saying: "I'm ok to merge this
in aggregator if you confirm the submission conforms to Simultaneous
Release requirements and that it is a stable URL that won't disappear"
would probably help, on medium to long term, to avoid bad contributions
to aggregator and then to make build more stable.
When I was a younger contributor to Eclipse, i did contribute some stuff
to the release train which broke some builds. It happened because I did
not understand enough the requirements and workflow of the aggregation.
I guess it's the case for some other contributors. Code review would
have prevented me from breaking build.
Time to review such a patch: a few minutes.
Time to notice a build is broken + to route error to the right
contributor + to disable the contribution + to rebuild: a few hours.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
