master.cfg.d

Maybe have the dir just be "config.d"?

discussion on the mailing list made me aware of a small issue, if folks want to use this as a replacement for importing local modules from master.cfg . All the classes defined in master.cfg or the other foo.d/* files that get exec'ed will get a new identity upon each reconfigure, which will cause spurious activity.

(basically the buildmaster will think that you've changed all the Builders that reference those classes, or the Schedulers or ChangeSources?)

hmm, but these days that's not as much of a problem as it used to be. Since the addition of Builder.consumeTheSoulOfYourPredecessor (boy was I punchy when I wrote that one), replacing a Builder with an exact copy doesn't actually lose any information. Schedulers will lose any builds that were pending (waiting for the tree-stable-timer to fire), but conceivably we could create a ChangeSource.consumeTheSoulOfYourPredecessor method. Some of the status plugins could be affected (if you had a subclass of the IRC bot, it would probably disconnect and reconnect on each reconfig).

On the other other hand, admins would always have the option of putting their subclasses in separate modules and importing those from the master.cfg.d/* files, giving them exactly the same behavior as the current code, in which they'd either have to use reload() or completely restart the buildmaster to trigger those changes.