New Planning Thoughts draft.

[david at lang.hm]

On Fri, 18 Apr 2008, Kim Quirk wrote:

> 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.

however, if you only make two releases a year the schools have very little 
choice about what they upgrade to.

if you have more frequent releases they can more easily make a choice 
between one that just came out (and hasn't been tested much, but has some 
more updates) vs one that has been out a little longer na dthey can be 
more confident doesn't have any major landmines still undiscovered.

> 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.

the compatibility of software is an important issue in any case. whatever 
your release cycle you are going to have times when you have mixed 
releases. and if OLPC achieves the deployment scales they are aiming for, 
you will start to have XO machines near each other that are controlled by 
different schools (think of the mix that you could get at a vacation spot 
during school breaks)

> 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.

I think more, faster releases are a better approach. the testing effort 
grows much faster then the count of changes (with the need to test 
combinations of things) so frequent, small releases are easier to test.

I don't view the backwards compatibility issue as a showstopper, becouse I 
see it as being nessasary in either case, it's just more obvious with 
frequent releases (which can be a good thing if it makes people do a 
better job)

David Lang

> 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 --------------
_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel