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

Am 28.01.15 um 22:40 schrieb Nathan Van Gheem:
> I'd also like to comment.
>
> If you are going to revert someone's commits, please let them know. It's
> very frustrating to find out a week later that your work has been reverted.

I agree that we have to make sure to include the reason for the revert 
in the commit messages. Sorry if I did not to this in the past. I will 
try to do this in the future.

Though, if another person does a revert that usually means that the 
committer ignored the failing tests in the first place. It should be the 
responsibility of the first committer to revert. I always try to send a 
message to the person who broke the build and I usually revert a commit 
only after the person did not react for at least a couple of hours and 
if other people start to commit on the broken build. This means there 
are usually lots of violations of our CI rules before I revert a commit.

For me it's frustrating that I have to revert a commit because people 
just ignore that they broke the build and sometimes they even ignore 
direct messages. In addition other people ignore the broken build and 
just continue to commit. This is the situation where I start to revert 
commits as fast as possible (and sometimes forget to notify people 
properly) to prevent a situation where things are getting too complex. 
When this happens nobody feels responsible because it is impossible to 
figure out which commits were responsible for the test failures.

To some extend things would become easier if we can improve our CI setup 
further. Though, there is no alternative to coming up with a set of CI 
rules and taking them seriously, if we want to be able to make a Plone 
release in a timely manner, without having to fix tons of tests up front 
before we can even start with the release.

> Lastly, I'll just echo the comments of others that our testing
> restrictions really does make it difficult to contribute and that it
> likely prevents me and other from contributing more.

Could you elaborate on this please? I see many things that could be 
improved in our CI process or even more in our development process. 
Though, I don't understand what "testing restrictions" mean in that context?

I'm perfectly ok with your approach of sending an email to the list 
saying that you will break the build and that it will take some time 
until it is green again. This is sometimes necessary if we merge larger 
feature branches. We just have to make sure that nobody commits on a 
broken build during that time.

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/