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

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.

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

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 
right away people start committing on a broken build making it 
impossible to figure out what went wrong. The more commits on a broken 
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.

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.

So, PLEASE REVERT ALL THE COMMIT YOU MADE YESTERDAY!

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.

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

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.

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

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/