[sugar] Update.1 schedule & trac usage... ***Please Read**

[Jim Gettys]

I'd recommend not closing the bugs until you ask for approval for update
(are finished with the set of bugs), rather than doing so immediately on
each bug.  But waiting to close until after testing in an update.1 build
hasn't worked out for anyone.

We're also going to go through a diff of packages at code freeze and
make sure nothing slips through the cracks that is fixed in joyride but
didn't get into update.1.
                                     - Jim

On Fri, 2007-12-28 at 17:08 +0100, Marco Pesenti Gritti wrote:
> On Dec 28, 2007 4:14 PM, Jim Gettys <jg at laptop.org> wrote:
> > I guess there may have been misunderstanding: since the beginning of
> > December (or maybe before), only things intended for Update.1 and issues
> > approved for fixing in Update.1 needing testing were supposed to be
> > loaded into joyride.  As such, there should be no cherry picking of
> > fixes needed, when you are at a completed state.
> 
> I don't mean cherry picking of single fixes/git commits, but cherry
> picking of packages from joyride to Update.1.
> 
> My understanding of the process is:
> 
> 1 rwh fix bug A in sugar
> 2 tomeu fix bug B in sugar
> 3 tomeu builds a sugar package with bug A and bug B fixes in it.
> 4 the package goes in joyride and tomeu test it out
> 5 tomeu request ApprovalForUpdate
> 6 marco or jg approves the package
> 7 dgilmore tag (in other words cherry pick) the package for Update.1
> 
> With this process, if ticket A and ticket B are closed *before* 5, it
> will be hard to track which packages needs to be tagged for Update.1
> (and likely that we will miss some of them).
> 
> Marco
-- 
Jim Gettys
One Laptop Per Child