Re: [Libreoffice] master & patch review process ...

Hi Michael,

On Mon, 23 May 2011 16:10:06 +0100
Michael Meeks <michael.meeks@novell.com>
wrote:

>       Which is bad; no-one denies that - *but* it also seems like
> you just saw it was broken, and left it - rather than fixing it: it
> also sounds like the problem was extremely trivial - some printf's
> left in some module (right?).

I just wanted to merge my local feature branch and test it. Since the
most likely bad commit was just minutes before, I pinged the
author of the commit about it on IRC, hoping that he would fix it.
The error itself was an unresolved symbol, which can be very easy or
rather nasty when there was a set of >10 refactoring commits before.

> > This is why we should prevent this from even happening as much as
> > possible.
>
>       Surely, not as much as is possible; surely in a balanced way
> when considered against the risks of making it too difficult and
> painful to contribute effectively (cf. OO.o process) ;-)

Oh, I dont want EIS back, that is for sure.

>       Fine - why not ? :-) will be easier with Nobert's single git
> repo.
Yes. It isnt yet which is why I was trying it on IRC first.

>       Heh - I feel your frustration. But I also know that
> -the-vast- majority of commits are small, localised changes that
> require no big, heavy-lifting process, and just get strangled by
> that. Sometimes they break things - true, but lets deal with that in
> a way that doesn't harm everyone else all the time ;-)
Not all the time: The original proposal was about syncing our big
changes to master, so that there is a known decent state of master
on all platforms. As caolan said, dont push major changes on Friday
9PM, when you wont look back at the tinderboxes on the weekend. After
all we have this great DSCM allowing us to push day later or so,
without anybody being hurt. ;)

>       Finally, it is worth noticing that master is of particularly
> bad build quality (ie. sometimes it breaks over the weekend) when the
> majority of the developers are working on building -3-4 and or -3-4-0
> in order to get a great release :-)
Sure, still I think we should keep commits on master and only
cherrypick back to release. See also the OGridControlModel snafu.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen