Re: [Plone-developers] Porting tests to plone.app.testing and removal of legacy packages

[Gil F. C. <gfo...@gn...>]

There is a failing test still, but somehow jenkins fails to report that one.

As jensens said is on p.a.testing.bbb ...

2015-01-28 16:40 GMT+01:00 Gil Forcada Codinachs <gfo...@gn...>:

> I did the last reverts (one at a time again and created new PR for
> them[1]).
>
> P.CMFDynamiViewFTI was reverted but still has two failing tests(?!)
> P.PloneLanguageTool was manually reverted[1] and is running now on Jenkins:
> http://jenkins.plone.org/job/plone-5.0-python-2.7-at/3597/
>
> If the above job does not end up in a green build, we will start to have
> to look somewhere else...
>
> Cheers,
> Gil
>
> [1] there were two more commits after the p.a.testing merge
>
>
> 2015-01-28 16:07 GMT+01:00 Timo Stollenwerk <ti...@pl...>:
>
>> 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:
>>
>> 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
>> Plo...@li...
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>
>