Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orion-dev] Process for converging on stable/release builds

Hi Matthias,

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.

John




From:        Matthias Sohn <matthias.sohn@xxxxxxxxx>
To:        Orion developer discussions <orion-dev@xxxxxxxxxxx>,
Date:        07/18/2014 04:11 AM
Subject:        Re: [orion-dev] Process for converging on stable/release builds
Sent by:        orion-dev-bounces@xxxxxxxxxxx




On Thu, Jul 17, 2014 at 7:43 PM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:
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:

http://download.eclipse.org/orion/drops/S-7.0S1-201407160323/index.html

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 / tests
- Hudson votes +1 if build / tests succeed or -1 if build /tests fail
- 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 branch
- if some submitted change turns out to be bad revert it (to my experience this happens very rarely)

--
Matthias _______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/orion-dev

Back to the top