#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 bernie):

 Replying to [comment:14 marco]:

 > 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?

 Yeah: hourly builds slimply require you to wait, on average, half an hour
 every time you want to actually *test* what you've built.

 Maybe it's easier for you sugar developers, because you can do most of the
 development with the sugar-emulator or just update a few rpms on a laptop.
 But doing things like rainbow and the update system really benefit by the
 ability to build your own images very frequently, as part of your regular
 development cycle.


 > 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.

 I've also been smelling this same smell.  This is why in my previous
 posting I was posing an open question rather than expressing a concrete
 proposal or a clear position.  Given his experience, I'm looking forward
 to hear Dan's opinion on this.

 To make it clear, my basic question was: do you see value in making the
 development process more distributed?

 I do.  And I see the joyride/xtest/rainbow branches that cscott created as
 a very useful innovation.  Every team or individual should be able to get
 something it when they need it.

 This doesn't automatically rule out Koji: multiple distribution *are*
 supported in koji.


 > 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.

 If you re-read my posting, you'll find that I'm not really proposing much.
 I'm just throwing my random thoguhts at you guys and asking for feedback.

 I'm very open to use Koji.  In fact, so open that I already went through
 the struggle of installing an instance on my deskltop over one month ago.
 I did it because I badly needed an environment where I could build *my*
 X11 packages for testing.

 Besides stable builds, which we all agreed upon already, my main
 requirement is very strightforward: the ability to create as many streams
 as we like.  Possibly on developer machines.

 What's not clear to me is what your requirements are: what parts of koji
 do you use and need?  What else do you need to work?  CVS?  pilgrim?  a
 cluster of build servers?

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