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

[Jim Gettys]

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. 

The approval for update step allows us to know when testing has been
completed for the particular issues, and allow the update.1 to generally
not regress (even though it would not necessarily have every fix present
in joyride). When testing of one or more bugs has completed, you can ask
for it to go into update.1; it is fine if this happens multiple times.
                                  - Jim



On Fri, 2007-12-28 at 11:17 +0100, Marco Pesenti Gritti wrote:
> On Dec 27, 2007 5:02 PM, Jim Gettys <jg at laptop.org> wrote:
> > Predictably, lots of people are on vacation, making the following
> > problem critical, as it is difficult for me to query people individually
> > on status as it might be at other times:
> >
> > Trac's (current) workflow is poor: we've had no good way to see what
> > bugs are "fixed" even if not in an update.1 build.  Noah Kantrowitz is
> > working on fixing this for us. There are much better workflow facilities
> > now available in trac, so we can have an "in QA state" and an "incoming
> > bug, not yet confirmed" state to help both QA and initial triage.  This
> > should help future releases, but I suspect changing horses now would be
> > unwise.
> >
> > But this problem, in concert with people being out on vacation, means I
> > lack good insight on key bugs left to fix for Update.1.  And a few more
> > nasty bugs have surfaced, of the variety that need some
> > implementation/testing (e.g. filling nand).
> >
> > So I think we need to slip Update.1 a week or two.
> >
> > 1) As a stop-gap measure for the Update.1 release (until we have the
> > better workflow available) to help the visibility of bugs left for
> > Update.1, *PLEASE* go through your bugs, and if you have *tested* them
> > as fixed in Joyride, please close the bugs.  The "verified" flag should
> > only be you've also verified it fixed in an Update.1 build.  Once we do
> > hit real code freeze, we can use the verified flag to let us all go
> > systematically through the more serious bugs to see if they've remained
> > fixed in the Release candidate builds we intend to ship.
> 
> Do you still want us to cherry pick packages into Update.1 (after
> ApprovalForUpdate) or is Update.1 going to be branched from Joyride at
> the time of the freeze?
> 
> If we are going to cherry pick, I think tickets should be closed only
> *after* a distro ticket to get the new package in Update.1 is opened.
> 
> Marco
-- 
Jim Gettys
One Laptop Per Child