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
Context
- Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ... (continued)
Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ... · Bjoern Michaelsen
Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ... · Michael Stahl
Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ... · julien2412
Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ... · Jacobo Aragunde Pérez
- Re: Changing mindset of core LO developers to the status of master -- was test infrastructure ideas appreciated ... · Wols Lists
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.