I'd been thinking about that. There are two places where it matters:1) in the tree above the cart sourceswe could skip those and just search for Rakefiles in the cart dirsthe all:rpm target rebuilds everything. The carts take the majority of the time and will likely have the lowest change rate as a groupthough individually new ones will change fast.2) in the root of the cart sources:tito just builds the package. it doesn't find and install build requirements, run tests or generate documentation.They're not conflicting, they're complementary- --I used the presence of a Rakefile at each directory so that a rebuild could be started at any level. it would be perfectly reasonable to require one in each package with standard builddep, rpm, testrpm, (unit)test, doc/yard targets while removing the boilerplate Rakefile at the intermediate levels. The one could either build at the package level or at the top of the tree but not easily "in the middle".From a maintenance standpoint that avoids the problem when someone adds a new tree (for what ever reason) but negects to add or maintain the Rakefile at each level.
The attempt was prompted by a sense that a new developer coming to work on the origin-server components would find themselves blocked and have to implement something like this themselves. I'd rather be ahead of them.Matt indicated concern about triggering rebuilds in localized components without rebuilding the matching parts of an upgrade. I see this as a fairly low risk. The use cases I see are:1) a component developer who is rebuilding their part frequently as they workThis person is going to be touching all of the relevant dependencies and rebase/rebuildIf their work is truly isolated they're going to be fine. If not, they will discover as a normal part