Hi, 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 yet. So: - 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. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice