On Dec 14, 2007 11:01 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > Declaring code freeze for Update.1 today would not see a rational > resolution of these issue. As promised, this is a release that is > driven by completion of content, rather than driven by necessity of > hardware schedules.
On the Sugar side, the main reason of the delay is that dealing with the various release process steps has been a lot more painful then it needs to be. We wasted a *lot* of time there. There are a few simple things which I think will improve this dramatically. * ApprovalForUpdate needs to be quick. Let's try to not get in the situation of having to suspend it for weeks again. Stuff accumulate and cleaning up the mess is very error prone. * The build master bug queue needs to be kept clean. *All* the approved packages needs to go in the next build. As soon as a package is in a build, the ticket needs to be assigned back to the owner for testing. Creating a separate trac user for this might help (build tagging tickets are mixed with other dgilmore tickets right now). * Testing changes in Update.1 is a requirement, so we need frequent stable builds, at least until the code freeze. We used to make these builds daily at a fixed time and it worked very well, let's get back to that habit. Thanks for the cooperation! :) Marco _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel