New Planning Thoughts draft.

[Edward Cherlin]

2008/4/18 Kim Quirk <kim at laptop.org>:
> 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.

Excellent ideas, both, in any case.

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

That is one class of target users. There are several others, including
developers, education researchers, and the wider public. Now that
Sugar packages have been integrated into an imminent Ubuntu release,
that wider public is quite wide indeed.

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

A division like Debian Stable, Unstable, and Testing would resolve
that. Those who want the bleeding edge software will be on notice that
they are part of the QA. We could still move bug fixes into Stable,
and all other enhancements into Unstable (or whatever we choose to
call them). Then schools would have the assurance that all students
have the same basic suite of compatible software, able to run all of
this year's interactive teaching materials.

> 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

I see no real reason why we can't have the best of both.

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

I have worked at eBay, where a large number of development teams works
on different projects, with a merge and rollout of a new set of
features every two weeks. I have also worked with several kinds of
Agile programming, where one of the goals is to have something
shippable every two weeks. There are other possibilities besides these
that we could look at.

> > Marco

-- 
Edward Cherlin
End Poverty at a Profit by teaching children business
http://www.EarthTreasury.org/
"The best way to predict the future is to invent it."--Alan Kay