> Generally speaking, I am in favor of backing otu changes that > break the world.
I should have caught this problem (mea culpa) but “break the world” is a bit hyperbolic. “The world” is broken much of the time, because very few of the developers on this project know how to fix *BSD portability problems. How would they, when nobody ever tries to educate them in review comments or elsewhere? If we just say that *BSD failures block all merges, but nobody tries to speed the process of fixing *BSD failures, then that slows down overall development too much. As I understand it, that’s why those results currently don’t count toward verification in Gerrit. Some of us have talked about instituting a delay or window in which patches that only fail on *BSD can be fixed up for that environment, without obstructing other development. If anyone has ideas on how to make that work, or has a different idea that doesn’t make *BSD the bottleneck for all development on all platforms, now would be a great time to share those ideas. _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
