Builds and release process ( was Re: Update.1 schedule and code freeze...)

[Marco Pesenti Gritti]

On Dec 14, 2007 11:01 PM, Jim Gettys <jg at laptop.org> 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