[Squeakfoundation]re: 3.5 release timing

[Doug Way]

Daniel Vainsencher wrote:
> 
> This is all fine, except that in most cases, we don't know or control
> what will be in a release in advance. The most we can do is try to
> influence it, by explaining what is important in our opinions and why.
> 
> I think it's more practical for us to be flexible about the content, but
> harsh about the timing/standards required for getting in.

It's a balance, but I tend to agree that having (roughly) regularly timed
releases, and then adjusting content to fit the schedule, seems like a good
approach.  So the timing is the more important of the two.  (I don't have an
entrenched opinion about this yet, though. :-) )

But we should still have a proposed list of content ready at the beginning of
a release cycle, as Craig suggested.

> I'm starting to agree, though, that what grand plans we do make, we
> should announce before the previous release is out.
> 
> About the contents of this specific release, I agree the project fix and
> the class builder fix are desirable (and are probably practical, since
> we have candidate fixes for both), but wouldn't reject out of hand other
> fixes posted if they are properly reviewed, tested, and very simple.
> Also, I think the font license non-issues should be smoked out finally
> by pulling in some apple-font removing package from SM.

Hmm, I like the idea of just having the two fixes, and the extra-short
release.  At this point, I think that removing the Apple fonts should probably
wait until the post-3.5 release.  (It's only a few weeks away anyway...)

I think the furthest I would go in considering other fixes is that, if another
bug comes in that generates as much real concern as, say, the project-writing
bug, and a good fix is available within the first week of the 3.5 cycle, then
we could consider that.  But we'd have to discuss it specifically on the SqF
list here, whether it was worth adding at that point.  IMHO the "default"
course of action is that we only include the two fixes.

I realize that this temporarily limits the usefulness of the new harvesting
system on the gsug/sqfixes page, but I think we could address that by coming
out with a 3.6alpha branch soon.  (Yes I know we haven't officially decided
that the next release will be called 3.6 and not something like 4.0, but for
the sake of argument let's call it 3.6.)

So, let's assume we go ahead with the current plan for 3.5 (only the two
bugfixes unless another major bug comes up, release on April 4th).  We can
discuss it a bit more, but I'd like to announce this on squeak-dev sometime
tomorrow as planned.

Then, I could harvest the two bugfixes and put them in the 3.5alpha update
stream.  Then, soon after that (maybe a few days), we might as well move 3.5
straight to beta.  At that point, we could offer the usual choice in the
update stream for whether people want to move to 3.5beta or join the new
3.6alpha update stream.

With 3.6alpha open, even while 3.5beta is still around, we could start
harvesting the fixes on sqfixes into 3.6alpha and see some of the faster
turnaround and "visibility" that we've been hoping to achieve.

> I would like to enlist at least all guides to help in making QA tags
> widely used. This requires, on the one hand, being the "bad people" and
> requiring more QA tags for submissions that don't have them, and OTOH,
> when review tags are added, doing our own review and highlighting what
> isn't good enough, to clarify what the tags actually mean.
> 
> Being demanding is sometimes considered neither fun nor popular. but I
> submit to you that -
> A. it may not be popular, but it'll be far more popular than having a
> slow/ineffective feedback cycles.
> B. It CAN be a LOT of fun if you get in the right, nasty mood for it ;-)

Yes, I am going to start doing this soon. :-)

- Doug Way