I am happy to start using Gerrit more,
but there are some issues with using it for this situation:
1) The Gerrit workflows appear to be
broken in the current Orion builds (bug 439345) so for everyone self-hosting
this is a blocker.
2) I'm not convinced it solves the same
problem, but it could be that I don't fully understand the powers of Gerrit.
As far as I can tell, Gerrit adds processes and checks *before* integration
with the main stream. Code review and automated tests catch some problems,
but many more slip through these initial checks and it is only after the
change is integrated and pushed on orion.eclipse.org and we start self-hosting
that we find the problem. Eventually we might have enough tests that this
becomes a rare event, but currently it is quite common. So far we have
no performance tests, and no page-level integration tests for the UI. Essentially
this appears to me the same as Anthony's "never introduce bugs in
master" proposal, which is great in theory, but until we are consistently
doing that it is not sufficient.
Having said that, if we can get the
Gerrit workflows working in Orion, together with automated build &
test for uploaded patches, I'm sure it would help us to reduce the number
of bugs introduced and might get us to the point where we no longer need
a stable branch.
Matthias Sohn <matthias.sohn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Orion developer discussions
07/18/2014 04:11 AM
Process for converging on stable/release builds
On Thu, Jul 17, 2014 at 7:43 PM, John Arthorne <John_Arthorne-G1DYhSM1WHTQT0dZR+AlfA@public.gmane.org
During Orion 7.0 we have completely
stopped doing milestones in favour of a more continuous delivery model.
We would like to produce regular (roughly weekly) stable builds that can
be deployed to orionhub.org
One issue with this is how to stabilize the code for a stable build without
disrupting ongoing development in master. After discussing ideas with various
committers I would like to propose a process of branching once per week
at a predictable time, and use that to converge on a stable build while
allowing master branch to continue development. https://wiki.eclipse.org/Orion/Continuous_Delivery#Stable_build_process
I have done a test drive of this process this week. I setup new "stable"
build in Hudson that builds from a branch: https://hudson.eclipse.org/orion/job/orion-client-stable/
I used this to produced a stable 7.0 S1 (Orion 7 stable build #1) that
I have deployed to orionhub.org
Committers please take a look at this proposed process and respond here
with any thoughts and concerns.
this sounds like a manual implementation of a process
pretty similar to the one supported by Gerrit.
So why don't we adopt the Gerrit code review workflow
instead to reach an always stable master branch ?
- Instead of pushing to master everybody would push (all
changes) to refs/for/master
- Gerrit creates a new change / patchset for reviewing
- new change / patchset triggers Hudson to run a build
- Hudson votes +1 if build / tests succeed or -1 if build
- other committers / integrator of the week review changes
pending in review and vote
- changes in review which got approved in review are submitted
- Hudson builds / tests resulting new version on master
- if some submitted change turns out to be bad revert
it (to my experience this happens very rarely)
orion-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visithttps://dev.eclipse.org/mailman/listinfo/orion-dev