The right tool for the job!? -- was Re: gerrit for 3-6, LibreOffice gerrit bot & wrong Merged status
bjoern.michaelsen at canonical.com
Mon Jul 16 01:28:32 PDT 2012
On Mon, Jul 16, 2012 at 09:45:36AM +0200, David Ostrovsky wrote:
> i am afraid, that you just try to translate your current (old)
> workflow and try to (re)-shape the new tool to match it.
> My understanding was (and is) that new tool requires new thinking,
> new approach and ... yes new workflow.
The basic premise that we require less review on master than on a release
branch is a sane and good one that has served the project very well. No tooling
should make us walk away from sucessful policies.
> But by letting still push everything (forever ?) to master directly
> and then bypass gerrit you jeopardise its main advantage: junk in
> junk out.
I trust our developers to make a good judgement on which changes they dont want
to bother their co-devs with and which better need a second look. On release
branches we have stricter policies, but on master the peer pressure of
everyone-is-angry-at-you-if-you-break-master should be enough to not have "junk
in" -- esp. if you could have submitted your changes to review first.
In the end, I expect less and less direct pushes to master once we have the
tinderboxes (with tests) in place -- we already do more than 10% of commits via
gerrit (and ~75% of all reviews) although the tooling hasnt really smoothed out
- we first aim to get all reviews to be done on gerrit
- then we can aim for increasing the amount of reviewed commits in general
(which is much less painful with gerrit)
So yes, the first aim is the currently important one and yes, for the migration
it is important that devs can smoothly adjust to gerrit -- as long as the devs
are not sleepwalking through gerrit we dont need to spend too much time on
building fancy things on top of it. So things like the maildrop for gerrit are
the important and relevant stuff right now.
More information about the LibreOffice