[sugar] [IMPORTANT] build and release process explanation

[Ivan Krstić]

Hi all,

I wanted to additionally clarify what's happening in terms of release  
engineering and build process as we approach shipping.

All former FRS tickets, as you might have noticed, were moved to what  
is now Update.2. Many of these are not bugs; they're tasks and  
enhancements, or relatively minor defects. We can't fix all of them  
for Update.1; it's not realistic.

So we need to cherry-pick tickets from Update.2 that we know have a  
reasonable chance of _actually_ being fixed by this coming Friday. We  
proposed in the past that this is done by tagging the bugs with  
'killjoy?' (and then 'update.1?'), as a bit of an overreaction to  
previous chaos in determining what goes into the builds.

Until Friday, we'll lift this requirement. Subsystem owners are  
responsible for figuring out which bugs of those that were retargeted  
for Update.2 can be fixed for Update.1, retargeting them accordingly  
in Trac, and getting them fixed by Friday. Do this judiciously.  
Retargeting in bulk what we can't do in time won't help anyone.

In terms of how builds are going to work -- we'll be using the  
joyride system:

     http://wiki.laptop.org/go/Build_system

If you don't yet have a real shell on dev.laptop.org, please alert us  
immediately. RPMs and .xo bundles that you place in your drop box, as  
described on the wiki page above, will get picked up by the joyride  
build system and added to the next (hourly) build. Joyride will  
install your particular packages over the base OLPC system assembled  
with pilgrim, like in the old build process.

AFTER we hit the Update.1 freeze on Friday, several things will happen:

* The current joyride build at the end of Friday will become the  
Update.1
   candidate build.

* New RPMs inserted into ~/public_rpms will _not_ get automatically  
inserted in
   the build. Don't try it.

* Any new code pushes require approval from the release engineering  
team. Again:
   anything new after Friday (bugs, code, etc) _requires_ approval.  
To obtain it,
   please send an e-mail to <rel-eng at laptop.org>. A release  
engineering team
   member will reply and CC devel@ or sugar@, whichever is relevant,  
with the
   approval or denial.

Please let us know if you have questions, and thanks for bearing with  
us through the madness of the last stretch.

Cheers,

--
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | http://radian.org