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

 I agree with marco's requirements and dcbw's solution.

 With a minor (or major) exception: in the '''long term''', I see the
 centralized model of a single koji server, or even a koji cluster, as too
 restrictive.

 A system where each and every developer must be given an account on
 koji.laptop.org, must wait for remote builds to complete and can't easily
 create personal forks of the distribution for testing... well...  I don't
 see it scale well.  At least, it doesn't have the "massively parallel"
 property which the kernel and git hackers go very proud of.

 I felt the need for an xtest fork for a long time.  And so had m_stone for
 rainbow.  And I'm sure marco and the other Sugar developers would have
 benefitted from a branch where they'd be free to test their experimental
 features.  If we don't get this, we'd push the build master for including
 half-baked and untested packages on the basis that we can't go on working
 otherwise.

 The good property we want from koji is a controlled build environment,
 which you get by specifying what goes in the buildroot and what other
 -devel packages you're pulling for the builds.

 Since we're not an academia and have no time to do academic research on
 build systems, my proposal is to go on and setup a centralized build
 server anyway, but set a policy for creating as many integration streams
 as people require.

 Additionally, we could document the full-blown procedure to create custom
 jffs2 images starting from source rpms.  All the pieces are there: yum,
 mock, koji, pilgrim... but the big picture is  hard to see because it's
 scattered in 10 different places.

 NOTE: some people may see this model as anarchic or unregulated.  On the
 contrary: it's the '''strictest''' QA you can reasonably come up with
 without paying a high price in terms of productivity!  Each tree (or fork,
 or distro...) has exactly one stakeholder and has the last word what goes
 in the particular build.  In contrast, the joyride model is a bazaar which
 nobody feels responsible for fixing.  Needless to say, one tree can be
 called "release" or "stable", and whoever is in charge for it will only
 bless-in the packages after they've reached reasonable quality.

 Thoughts?  "you suck, shut up!" would be ok too...


 NOTE2: So far, we have more than enough material for discussion without
 even starting to think about how we'll do version control of packages.
 RedHat does it with a huge CVS tree.  I'm not sure we can keep using it if
 we diverge too much from Fedora, and anyway it seems to me that CVS makes
 the workflow a lot heavier.  But let's discuss this topic later when we've
 settled the build system.

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