[Squeakfoundation]3.6 release timing (was Re: Shrinking alpha image)

[Daniel Vainsencher]

[Cross posting moves threads, cycle >~4 mo]
Sure.

[Sm 1.1 in Squeak 3.6, me or someone as release content prognosticator]
If someone does want the job, they're welcome to it. As for me - Goran,
I haven't had as much time/inclination to help with SM as I thought I
might, but let me know if you need testing/someone to play XP customer,
or any other specific kind of help. I wouldn't say that 1.1 will or even
should be in 3.6, but I'd be damn happy to help it get there! :-)

[3.6 harvesting to start soon]
Sure. I'll be looking at the recent posts of removal scripts and
reviewing them, so we can start putting some shrinking into the image.

Daniel

Doug Way <dway at riskmetrics.com> wrote:
> 
> goran.hultgren at bluefish.se wrote:
> > 
> > (crossposting, well - it seemed good)
> 
> (Yeah, occasional crossposting is probably unavoidable.  Perhaps we should
> only crosspost when we want to shift discussion from squeak-dev over to the
> SqF list (and maybe vice versa).  Then all follow-ups should only be posted to
> the newly added list, as I'm doing here.  For example, squeak-dev can still be
> a place where planning-related discussions will often happen (since it's a
> free-for-all), but in more of a brainstorming phase, and to get as much input
> as possible from the community.  But then when final decisions need to be
> made, the discussions should happen here on the SqF list.)
> 
> > As I see it the plan Doug has laid out seems fine. I mean, we aren't
> > really maintaining two images - we are maintaining the smaller one and
> > making sure that the "full script" works.
> > 
> > BUT... may I suggest that we set up a goal for 3.6 that SM1.1 is reached
> > before release? Otherwise this "full script" will have problems, since
> > it can't refer to specific versions of packages.
> 
> Sounds like a good idea.  I was guessing that SM1.1 would be out relatively
> soon (within 1-2 months?)  Making it a requirement for 3.6 could give you an
> extra incentive. ;-)
> 
> > And btw, who of us guides should be in charge of making sure that we pin
> > down the list of planned things for 3.6? I have seen numerous posts on
> > this subject but someone needs to collect these into a "big list" that
> > we can condense somewhere and come up with "The Grand 3.6 Plan". In
> > short - who should be the "Release Boss" for 3.6? :-)
> > 
> > And the gist of that plan should of course be summarized on this page:
> > http://swiki.squeakfoundation.org/squeakfoundation/79
> > 
> > Daniel? Tim? Ned? Craig?
> > 
> > Personally I would like to keep my focus at you-know-what and Doug has
> > already taken on enough IMHO.
> 
> Right.  Although I am sort of the "Release Master" or "Implementor", meaning
> the guy in charge of moving the release from alpha->beta->gamma->final, and
> making sure it happens reasonably on schedule.  But yeah, someone else should
> probably be in charge of pinning down the release "content".
> 
> > I think Daniel would make a greate Release Boss... :-)
> 
> I might nominate Daniel also, partly because he's posted on the topic in the
> past, and his current role as guide of "image detanglement" is somewhat
> nebulous and is partly covered by Ned's and Craig's roles anyway.  But if he
> doesn't want to do it and someone else does, that would be fine, too.
> 
> On a related note:  As the release implementor (or scheduler or whatever the
> best term is), I'd like us to come to a decision on when we want to release
> 3.6.
> 
> The last few Squeak releases have typically had 6-12 months in between each
> release.  I'm pretty sure that most of us agree 12 months is too long.  There
> were some suggestions on squeak-dev of having six months between releases, or
> having them every three months (quarterly), along with some nonsense about
> having them once per month. ;-)  My initial thoughts were to have them every 4
> or 6 months.
> 
> Another alternative is to not have a regular schedule, but to just come up
> with a list of features we'd like to see in the next release, and then put out
> the release whenever it gets done.  But I liked Daniel's argument about having
> the release timing be a higher priority than the content.  That way, people
> can depend on new features coming out on a regular basis, and we won't have
> releases that drag on for a year.  If some features on the to-do list aren't
> finished by the time we're scheduled to move to beta, they get put off until
> the next release.  (Of course, we'd try to make sure the most important
> features got worked on right at the beginning of the alpha cycle, so at least
> they would be finished.  In a dire situation, we could postpone a release, but
> the general rule would be that the timing is more important than the content.)
> 
> Assuming we go with a regular schedule, I would propose having them every 4
> months.  This was about how often the releases happened up until 2.8, I
> think.  Having them every 6 months would work too, but I like the idea of
> moving things along a little bit faster.  Having them every 3 months feels too
> fast to me, though... my release duties would happen at a more hurried pace
> and might start to impinge on the "fun" aspect of being a guide.  Also, that
> might not allow enough time for a reasonable beta cycle along with a longish
> alpha cycle.  I'm guessing our beta cycle should be something like 5-6 weeks?
> 
> And having releases every 4 months would make the tri-annual releases, which
> brings up the "triad" again. :-)  Anyway, I could be convinced to go slower
> than this, but I don't think I'd want to go any faster. 
> 
> If we stick with the "First Fridays" release date, that would put the release
> date of 3.6 on August 1st.
> 
> We can then come up with a list of content that we think can reasonably get
> done in that time.
> 
> Thoughts on this?
> 
> - Doug Way
> 
> 
> p.s. Even before we decide on the content for 3.6, I think we could get
> started on harvesting fixes for 3.6 right away.  I'll send out another note
> shortly about this... getting the harvesting rules nailed down so I know what
> to do.
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation