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

Marco Pesenti Gritti mpgritti at gmail.com
Sat Dec 15 07:35:50 EST 2007


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



More information about the Devel mailing list