[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A case for layered development/build/test/deployment tools.



Premature "send" button....


On Wed, Mar 20, 2013 at 12:56 PM, Mark Lamourine <markllama gmail com> wrote:
I'd been thinking about that.  There are two places where it matters:

1) in the tree above the cart sources
  we could skip those and just search for Rakefiles in the cart dirs

  the all:rpm target rebuilds everything.  The carts take the majority of the time and will likely have the lowest change rate as a group
  though 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.

Would that be preferable? (Rakefile next to .spec and Rakefile at the root of origin-server) ? 
 
----
 
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 work
  This person is going to be touching all of the relevant dependencies and rebase/rebuild
  If their work is truly isolated they're going to be fine.  If not, they will discover as a normal part

a normal part of the development process which we all go through.

  2) a component developer who means to contribute back
   This person will run the CI tests on their branch as part of their development process.  This will uncover
   emerging conflicts.

I can imagine someone building or changing a component in a way which is incompatible with something else, but I can't imagine them blaming us for it when the updates are all freely available and rebase/retest is standard practice.

- Mark

--
----
Mark Lamourine <markllama gmail com>
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]