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

On 2015-01-28 08:54, Timo Stollenwerk wrote:
> Am 27.01.15 um 22:11 schrieb Jens W. Klein:
>> Well, tests on the branch were green. So why after merge not on master?
>
> Because obviously the branch was not 100% in sync with the 5.0 branch.
> Our setup with checkouts and mr.developer is complex. Things like this
> happen all the time. This is why it is so important to do it step by step.

Sometimes this might be ok, in this case it was to many stuff at once. 
It would take days.

>> If this all fails that hard we need a better process. Merging is always
>> a huge PITA at the moment.
>
> The problem is that you just merged lots of pull requests at the same
> time without checking the Jenkins jobs. Sorry, but you can't just
> completely ignore our process (e.g. the CI rules) and then complain
> about it. If you would have sticked with the CI rules, we wouldn't have
> a problem now.

Sorry, in this case a classical "Break it and fix it" is much more 
efficient. As you may have noticed with exception of plone.app.upgrade 
and one revert everythings is fine. I did not merged my 
plone.app.upgrade fix, because our process has a four-eyes principle in 
merging branches, so I made a pull request.

> For me this is highly frustrating, because I always monitor the Jenkins
> status and try to fix thing if necessary. If I don't revert commits

You shopuld not stare at jenkins all the time, its not good for your 
overall mood ;)

> right away people start committing on a broken build making it
> impossible to figure out what went wrong. The more commits on a broken

An do not revert early, first ask the people involved. Its a community. 
So first communication, then merge. Btw. I was on #plone most of the  time.

> build there are, the more complex things get. There is a good chance
> that if you don't revert immediately, that we won't be able to get a
> green build without serious effort.

In this case we can revert anyway. I know Plone in depth and meanwhile 
the testing setup isnt a pandoras box anymore to me too. So fixing 
things is usally less effort than fighting with git.

> Continuous Integration is a process not a tool. Our tools might not be
> perfect, but if everybody would just stick to the CI rules we would have
> a green build most of the time.

Yes. But CI also says if it breaks, fix it together as a team. Not 
revert it.

> So, PLEASE REVERT ALL THE COMMIT YOU MADE YESTERDAY!

No. It doe not matter how loud you write it. Merge plone.app.upgrade and 
all is green. Why do you want me to produce new work, if all is fixable?
>
> This is the only sane way to get a green build again. You can't just
> break hundreds of tests and then leave it like this or expect other
> people to clean up the mess.

Wrong. I fixed it already. I dont expect anything from other people. I 
only expect them to keep calm.

>> We can try now to fix the stuff on masters or we take days until all is
>> merged piece by piece. Each test run takes ages. That way we never get
>> plone 5 out of the door. Probability to break the build from even green
>> branches is bigger than that it works. This a incredibly turn-off.
>
> I'm more than happy to merge the commits one by one (something that I
> already started btw. I just stopped because there are open issues),
> after you reverted your commits. If you don't like the CI rules, please
> feel free to make a different proposal.

You did not write a word that you started it. You may want to drop a 
line on news and #plone? If you had communicated this I did not touched 
it at all.

> Though, I'm really tired of discussing the basics of our software
> development process over and over again. Do we really want back to the
> old development process where everybody just broke whatever they wanted
> and David and a few others have to clean up the mess before each
> release? This is what really slowed us down in my opinion.

No, test driven and CI is fine. You did not understand what I meant. But 
I explained it above.

> Personally I don't want to waste my time cleaning up things that were
> trivial to fix by others if they would have sticked with the CI rules.
> If this is the opinion of a minority, we might want to find another CI
> team leader...

You make a good job. But you should accept, that sometimes breaking and 
fixing/reverting things is easier and more efficient. Maybe the new 
testing process you talked about helps a lot to avoid such situations at 
all and introduces a proces, where CI finally works.

So please do me a favor and have a look at
https://github.com/plone/plone.app.upgrade/pull/25
this may need some optimization as Johannes commented already, but as is 
it just works.

An it makes the build green.

Afterwards I'am happy to look at the Archetypes test problem.

Jens

> 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/
>


-- 
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
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/