New Planning Thoughts draft.

[Kim Quirk]

In my experience running QA teams and releases for commercial projects,
small fast releases require (or imply) quite a bit of focused process and
really good automation on the testing side.

Also, after other discussions on this list, it seems like there are two
other items that drive 'major release' twice a year and a few bug fix
releases in between:

1 - Our target users (mostly schools) will not be upgrading often, and many
will require weeks or months of their own testing before they do upgrade
thousands of computers.

2 - From a support perspective, this audience will probably require that we
support a major release for an entire school year. If we offer too many
releases during that time, we will not be able to keep up with the backward
compatibility matrix of releases that have to work with other releases. If
kids upgrade on their own, will they work with the older version that was
installed on 90% of the other laptops, etc.

I think if our product were aimed at developers or if it was a server-based
product where we could control the releases and there were no backward
compatibility problems, then it would be great to have many small, fast
releases.

Kim


On Thu, Apr 17, 2008 at 7:54 AM, Marco Pesenti Gritti <mpgritti at gmail.com>
wrote:

> On Thu, Apr 17, 2008 at 1:23 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net>
> wrote:
> >  I see this too as a hard problem and don't really have experience
> >  neither. What I would expect is that working on frequent time-based
> >  releases with features slipping as needed works best for projects like
> >  linux distros, where slipping a feature grossly means not updating a
> >  set of packages to the latest stable version.
>
> Even linux distro (Fedora at least,), doesn't actually do focused
> releases. Roughly, they set a timeframe and they get in everything
> which is ready by that date. This is very easy for a linux
> distribution. It would be harder on the Sugar codebase but still very
> much feasible, it's the same approach of GNOME releases.
>
> Though Michael proposal goes a step further. We would be focusing only
> on one (or a very limited number) of goals per release.
>
> Marco
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080418/0835cafa/attachment.html>