Possible goals for future releases (was: Re: Let's Release 3. 4)

Hannes Hirzel hannes.hirzel.squeaklist at bluewin.ch
Sun Mar 2 18:19:40 UTC 2003


Marcus

Marcus Denker <marcus at ira.uka.de> wrote:
> On Sat, Mar 01, 2003 at 11:13:42AM -0800, Tim Rowledge wrote:
> > Hannes Hirzel <hannes.hirzel.squeaklist at bluewin.ch> wrote:
> > 
> > > release cycle - 10 days alpha - 10 days beta 10 days gamma) and then
> > > switch to your proposition of quaterly releases?
> > Not Enough Time To Do Anything.
> > 
> 
> I have this impression, too. 
> 
> Hannes, remember: We are here to have fun... deadlines are something
> you'd need to pay me for.
> 
>       Marcus
> 

Well the proposal I came up with is to have a one month cycle only for
3.5  and 
then switch to a quaterly release scheme.

Daniel Vainsencher gives a reason for this
http://lists.squeakfoundation.org/pipermail/squeakfoundation/2003-March/
000986.html

>Suggestion - make 3.5 a very short release, consisting mainly of getting
>as many fixes in as we can, and giving them a proper testing. It's an
>opportunity for us Guides **to warm up at doing the whole process**
>ourselves. I'm talking about a time scale of 1 month total - 2 weeks
>alpha, 1 week beta, 1 week gamma, release. We start with specific, very
>doable goals (maybe even decide in advance a prioritized list of fixes
>we want to get in, not trying to catch up with everything that's up for
>harvesting), and basically spill them all into the update stream on day
>one, with the rest of the time for integration. Fixes that aren't ready
>for integration (meaning, posted tested, and reviewed by someone) by the
>end of week 1 will wait for 3.6.

(emphasis mine)

Cees de Groot favours a well having a quaterly release schedule.

This means that the amount of new things you have
to put in a release may vary. If something doesn't make it
for the current release then it will be put in the next one. 
No big deal. I do not see that this diminishes the fun.
But other people may have other preferences.

This brings us to an important question is of course - 
what does it "cost" (in terms of time , "non fun work", frustration) 
to do a release?

I am still under the impression that finalizing a release is doing
 some checking procedures, running some scripts and uploading
the image to the library. But of course there might be more things
involved here than I am aware of. I think it would be good
to have a rough idea people have to put in such a thing.

As you know in XP cycles they have releases for example every week.
>From this perspective having a one month release once doesn't seem
such a big deal.

The whole issue is open to discussion - for exactly this
reason I started this thread. I would like us to list the pros and
cons of various release schemes - probably on a squeakfoundation
swiki page which is accessible from 

Life cycle of a release  
http://swiki.squeakfoundation.org/squeakfoundation/89
or
Release Plan  http://swiki.squeakfoundation.org/squeakfoundation/79


The point is: We have to decide between goal oriented release schemes
vs. 
schedule based release schemes. 

At this moment I favour having more releases than we had now.
I think it would motivate people considerable because they see that
people 
are active and their contributions will show up in due time. What do you
think
for example about MCP. Is it a motivation for them not knowing
if their work will perhaps be included in June, maybe
October maybe next March. I really think we need some synchronisation.

But for sure - keep up the good work!

Hannes



P.S. An somewhat modified release scheme could be

3.5   final beginning of May
3.6   final beginning of August
3.7   final beginning of November
3.8   final beginning of February 2004 

to avoid somehow the "deadlyness" of the "deadlines".  "I do not get
paid for this!"



More information about the Squeak-dev mailing list