#4256 NORM Never A: Killjoy, stable builds

[Zarro Boogs per Child]

#4256: Killjoy, stable builds
---------------------+------------------------------------------------------
  Reporter:  marco   |       Owner:  kimquirk      
      Type:  defect  |      Status:  new           
  Priority:  normal  |   Milestone:  Never Assigned
 Component:  distro  |     Version:                
Resolution:          |    Keywords:                
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by marco):

 Replying to [comment:12 bernie]:
 > Sorry if I reply shortly after to argue against myself, but it just
 occurred to me that perhaps it doesn't take that much effort to extend the
 temporary build system done by cscott to do what we desire (i.e.: stable
 binaries).
 >
 > If developers were asked to drop source RPMs in their ~/public_srpms,
 directory, what would it take to build them?
 >

 Heh you are confusing me! First you post about a blue sky view on
 distributed packaging and after two minutes we are mocking up a custom,
 minimal build system which we are going to have to refactor and expand as
 soon as more contributors and a *little* larger set of features will be
 required.

 I would like our decision process to be a little more rational than that.

 > The only thing I disliked about the joyride infrastructure was that
 there was no way to trigger a build immediately, so you either had to bug
 cscott, or wait until the next cronjob run to test your jffs2 image.
 >

 Oh come on, hourly builds are lovely but let's not bring it at these
 extremes. Can we use a little more rational parameters then I like/dislike
 to evaluate things?

 > This is more of a question than a proposal: do we like to have a
 significant set of Koji feaatures?  Because if we do, there's no point in
 reinventing the wheel, but if we don't Koji is way too much infrastructure
 for what we *really* need.
 >

 I don't have concrete experience in this particular field, Dan wrote the
 Fedora extras build system so he could comment on it much better than me.
 But this smells exactly like the typical pattern you end up unnecessarily
 reinventing the wheel. Unknown requirements coupled with "what exist is
 much more complex than what we really need". And than you will soon
 discover than what you really need is much more complex than you thought.

 If you are proposing to drop our current build system completely, please
 flesh out the concrete requirements, verify if they are in contrast with
 what Koji is and the direction it could evolve, and make sure we have the
 resources to write one that better fits the requirements.

-- 
Ticket URL: <https://dev.laptop.org/ticket/4256#comment:14>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system