Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ...

Wols Lists antlists at youngman.org.uk
Fri Jun 12 04:03:41 PDT 2015


On 12/06/15 09:41, Jacobo Aragunde PĆ©rez wrote:
> El 11/06/15 a las 08:44, David Ostrovsky escribiĆ³:
>> On Wed, Wed Jun 10 12:22:53 PDT 2015, Norbert Thiebaud wrot
>>
>>> All that being said, none of that matter if the culture does not
>>> follow. no amount of CI can make people care.. what set the tone is
>>> the core developer group, the rest of us looks around how it is done
>>> and emulate the behavior.
>>
>> Nothing causes more pain, frustration and disappointment than
>> unfulfilled expectations.
>>
>> I expect that master is always green. My definition of green is:
>>
>>   $ make check
>>
>> with --enable-werror is passing on all three platforms: Linux|Mac|Win
>> 64.
>>
> 
> In my opinion, this should be so. It does not make sense to me to have a
> "bleeding" branch, you can always work on a feature branch and rebase it
> on top of master every now and then to have a similar, unstable environment.
> 
> The solution to have a green master could be adding some more automation
> to our Gerrit; we already can push commits there and get them checked in
> the three main platforms by Jenkins. Like Miklos suggested in this email
> [1], we could push the patches to Gerrit with CR+2 and get them merged
> automatically by Jenkins when it sets the V+1. It would require some
> work on Gerrit or the Jenkins bot - or both.
> 
So it sounds like my "bleeding" branch already exists, and it's called
Jenkins, but it's not working properly. Fine, let's fix it.

So. We need to get rid of the mindset that "we can't guarantee all
obscure configs will work, so let's not (try to) guarantee that any -
including common stable - configs will work at all".

How many configs do we need in Jenkins? Default Mac install, default
Win64 install, a couple of common developer linux setups. No patch
should be applied to master until Jenkins says it compiles and builds
fine across all STANDARD setups.

So the naive/newbie/novice developer can download master, knowing that
it SHOULD NOT BREAK unless they've got some weird config. Even a newbie
should know enough to expect a weird setup to cause problems.

I guess the standard setups would be default Fedora, latest RHEL, latest
SUSE, can't remember what the openSUSE rolling release is called, and
Debian testing and the latest Ubuntu.

Note I have not included my setup, gentoo :-). It'd be nice to include
things like gentoo/Sabayon/Arch etc etc but they're probably too much of
a minority. Maybe we should encourage distros to provide a
"libreoffice-dev" package, and say that it's their responsibility to
provide the relevant Jenkins test environment :-)

But we really should be able to guarantee that if you are running a
*mainstream* system in a *standard* developer config, that master should
compile and build without problems. If that means defining what we mean
by "mainstream" and "standard", then provided it's a pretty much
consensus definition that's fine.

Cheers,
Wol



More information about the LibreOffice mailing list