Re: Porting tests to plone.app.testing and removal of legacy packages

On Wed, 2015-01-28 at 16:07 +0100, Timo Stollenwerk wrote:
> Am 28.01.2015 um 14:30 schrieb Johannes Raggam:
> > Please track these reverted packages. The pull request on that packages
> > is closed and if we forget to revert the revert, the changes are lost in
> > history.
> > 
> > I'd rather give people a bit more time, say 48hrs or try to fix the
> > breaking tests myself. Everyone should feel responsible to fix a failing
> > test.
> 
> I strongly disagree. If we have the build broken for a longer period of
> time we basically have two options:

I was just sayin'... since I fully understand the purpose and necessity
of continuous integration and our test framework, I don't have much to
say against it - and I don't come up with better ideas.

What I was complaining above was the revert policy, which feels a bit
too eager to me. I prefer fixing tests. I FULLY UNDERSTAND, that you're
not the guy who will fix it - you just won't be able to do anything
else. Of course the guy who broke the build is in charge of it.

But as long as the reverters don't loose track of the reverted changes,
and the commiters are notified about reverts of their changes, the
revert policy is absolutely OK.

Don't forget, I really value your work on this topic and I'm glad you're
leading the testing team!


> 1) People stick with the CI rules and do not work on Plone at all if the
> build is broken. Do we really want one person to be able to block every
> other Plone dev for 48 hours? Who is going to check that? Who is going
> to act after those 48 hours? Do you want to do this manually?
> 
> 2) People ignore the CI rules and commit on a broken build. This leads
> to a situation where it is impossible to figure out who broke what.
> Nobody feels responsible and we have a red build forever (e.g. the old
> way of doing things).
> 
> "Everyone should feel responsible to fix a failing test." equals "nobody
> really IS responsible".
> 
> I would consider our CI to be completely broken in both scenarios.
> 
> > Especially because on the Plone 5 AT job it's IMO not that urgent to
> > have a green build within a few hours.
> 
> My experience with CI systems is that saying "it is not that important"
> is the worst thing you could do. If we start saying that things aren't
> important and that we can fix it later, it will be broken forever and
> nobody feels responsible.
> 
> The beauty of a well tuned CI system is that it gives developers
> feedback immediately if they break things, so they can fix it
> immediately and with not too much effort. If another person has to fix
> this later it cost way more effort (and is also a bit unfair in my
> opinion). If we let that core principle of CI go, we loose most of the
> advantages.
> 
> Timo
>

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlTJT98ACgkQW4mNMQxDgAdCQQCfblm7rlY4Z0wrCF71BawQDsUt
/CMAoM29QPP2k1S1vNrHpDPSQCIslFGR
=fylX
-----END PGP SIGNATURE-----