On 9/21/10 11:24 CDT, Steve Schveighoffer wrote:
But I've been following this discussion quietly, and I don't really understand the objection to checking in changes that break other builds. It's not like checking in changes is a release, so it has no bearing on people who aren't actively developing phobos/druntime. Isn't it enough for Brad's automated builds to maybe just post an email to this list when a build fails (after he changes it to be triggered by checkins of course)? And then it's just on the developer to make sure it works on his system at least (shame on you if you checkin a change that wasn't tested in at least *one* system). In other words, why should each developer check all builds when we have an automated system that does that?
The idea is that the trunk should be clean such that people can rebase their code freely to benefit of the latest source and avoid conflicts when checking in. The current system discourages synchronization. Even with the automated build in place, and even if we know that yesterday's build succeeded, there's no info whether the build would work with whatever is in the trunk. Ideally the cycle is change code -> make sure it builds -> commit.
Andrei _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
