+1 for "green master" policy in the sense that is important to keep
master green.
I do not vote for pushing into master via script (as described in [1]),
so that it is possible to push code that noone except for its author has
ever seen. Travis will never complain about missing tests, missing
JavaDoc, inefficient code, bad design ...
I am strongly for a "four eyes" principle - that all (non-trivial) PRs
should be reviewed by a human != PR submitter.
I do not vote for having a single (or a small number of) appointed
gatekeepers, because it does not scale (and perhaps gives too much power
to small group of people).
The PR submitter should be responsible for organizing a proper review by
a person of his choice.
The reviewer should:
* ensure that the general quality (efficiency, test coverage, JavaDoc)
of the new code is OK
* ensure that the new code works on top of master
(anyhow: jenkins, local, travis, ...)
* push to master.
[1]
http://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html#ho...
-- Peter
On 2014-11-26 11:20, Heiko W.Rupp wrote:
> Am 25.11.2014 um 20:28 schrieb mike thompson <mithomps(a)redhat.com>:
> I guess I was making more of a distinction that we are dev mode right now. Start of a
new project(s). Nothing has been QE’d. Right now, we are releasing about about every 4
weeks (but no real schedule).
> If you have something to commit in that 2 week window then it will become part of the
release. If not, add it to another 2 week window.
This will only work if we stick to a "green master" policy.
See e.g.
http://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html#ho...
and linked blog(s).
There may be technical issues like jenkins / nexus / ... not available that prevent a
green build. But if we take those
aside, but let's put those aside for a moment.
I have seen/done myself commits where I accidentally forgot to commit a new or changed
file and the built failed.
If that goes to master, we have a situation, where basically everyone is blocked as they
can not rebase from master,
the release can not be cut and so on.
So when all development happens on branches / personal repos and requests to include in
master are done as pull-requests,
the CI machinery can build the pull-request (which we have in RHQ and rhq-metrics
already).
And only if this build succeeds a "gatekeeper" (*1) may merge that to master.
There may be situations e.g. if 2 developers work in the same area where a 2nd PR needs to
be re-CI'd and may fail after master + 1st PR, but that still allows to keep master
green.
Luckily with a much more modular overall project (metrics, alerts, msg, .... ) the chance
that people are stepping on the toes are smaller.
Working in a branch / PR fashion does not automatically imply long running branches with
all the potential merge conflicts, but can be still done in small chunks.
In fact we may just live that with breaking features into smaller chunks, one per
"sprint" (there it is :-).
Take alerting for as an example: in RHQ we have probably 8 classes of comparators. We can
develop all 8 in one go in a long run or just have one comparator class per PR. When the
sprint it over, we deploy the result(*2) to a SaaS (*3) and the user can use that first
comparator class. We can get feedback (e.g. on usability) and after the next sprint, the
user can use one or two more and so on.
And if a comparator class takes more than 2 weeks of the sprint to implement it is no
issue, as there are no partial artifacts in master that need "fixing" before
release.
Heiko
*1) this may be mechanical by a script or a human (other than the committer) or ...
*2) In fact there are good number of projects out there that deploy daily or on every
commit or so
*3) while the end goal is of course to have some downloadable .zip to run, deploying to a
well-known place is still appealing
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel