re: 3.5 release timing

Hi Doug--

> We would need to put some limits on the number and kind of bugfixes
> that are accepted...

	Indeed; ideally a release version has a list of scheduled features
attached to it *before* any work starts. I think we should strive for
that. I think "Squeak 3.5" should evoke a very concrete list of changes,
as opposed to merely a guideline about the kind of change that will be
accepted. The latter just invites last-minute submissions, dragging out
the release process.

	Also, ideally, the naming, feature-scheduling and timing for a
particular version is finalized by the time of the previous version's
release. At the latest, the discussion is finalized during the previous
gamma (often having the useful side-effect of appeasing those whose
not-quite-critical-enough submissions were deferred :). So, for example,
I hope we can finalize the schedule for <the-release-after-3.5> by the
time we release 3.5. In fact, I'd even go so far as to make the next
release schedule an official feature of each release. :)

	If the 3.5 schedule were up to me...

	3.5 would include the project-writing fix, the class-builder fix, the
next release schedule, and nothing else. I would set a release date of
the next first-Friday (4 April), as it seems like a short cycle (since
the principle writing seems to be finished). First Fridays are simple
and memorable, and moving faster than monthly is both more difficult for
the community to keep straight and not really feasible from a labor
perspective. If possible, make sure the release is available by the
stroke of midnight at the beginning of release day, GMT, to avoid
timezone confusion (no one can say it's late :). If a release slips, go
to the next first Friday; it's just simpler that way. I wouldn't worry
about having lots of small releases, you won't run out of minor numbers.
:)  (E.g., the next minor release after 3.9 is 3.10, etc.)


	thanks,

-C

--
Craig Latta
improvisational musical informaticist
[email protected]
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]
From [email protected] Mon Mar 10 08:48:10 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 32638 invoked from network); 10 Mar 2003 08:48:10 -0000
Received: from ns.bluefish.se (HELO leia.bluefish.se) (213.212.22.234)
  by mail.theinternetone.net with SMTP; 10 Mar 2003 08:48:10 -0000
Received: from [213.80.63.110] (helo=aSqueakSystem)
	by leia.bluefish.se with smtp (Exim 3.12 #1 (Debian))
	id 18sIx5-0005WM-00; Mon, 10 Mar 2003 09:48:07 +0100
X-Mailer: Celeste 2.0.4917
Date: Mon, 10 Mar 2003 09:47:16 +0100 
Subject: [Squeakfoundation]RE: Your stewardship(s)
In-reply-to: <000f01c2e5a7$259472a0$8ef7fea9@atlantis>
From: [email protected]
References: <000f01c2e5a7$259472a0$8ef7fea9@atlantis>
To: Discussing the Squeak Foundation
	<[email protected]>
Message-Id: <[email protected]>
cc: 'Hannes Hirzel' <[email protected]>
cc: 'Brent Vukmer' <[email protected]>
cc: 'Doug Clapp' <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2003 08:48:11 -0000

Hi guys!

(Damn, 157 unread monday morning - hmmm, this is almost getting hard to
keep up with. Just so you know, I read sqf first carefully and then
maybe a bit more lax on squeak-dev. IMHO the traffic there is getting a
bit... well, quite a few posts with not so much content. But hey, that
is unavoidable as the community grows)

"Andreas Raab" <[email protected]> wrote:
[BIG SNIP of stuff I agree/understand/whatever]
> Most problematic at this point is that there is no API for any of the
> package that a client can rely on, no dependencies, versions etc. In the

Yes, true. But versions and dependencies are coming. And with them the
little idea of mine with "backwards compatibility level" of a package
release could hopefully remedy the lack of a declared API.

> days of the monolithic image that wasn't as big a problem as you could
> simply browse all the senders of some class/message to see where it's used.

Yeah, that is a "problem" I also have been thinking about. Perhaps
someone could set up some form of server somewhere that maintains
indices of senders/implementors and in which package release they are.

Then you could send some sortof of simple query over to that server and
get a result back. This would at least make it easier, you could see if
someone uses a specific method at all - or what package releases do.

[Hmmm, it feels like I am always proposing some new infrastructure of
some kind...]

> With SM, we need a more declarative style that tells both, clients and
> framework developers which methods can be relied upon and which can't.
> Without this, maintaining a package simply becomes a nightmare.

Are you sure? I mean, don't you think a little bit of documentation on a
package might suffice? So that it is obvious what classes/messages are
meant to be used from outside? And if we combine this with a more unit
test centric model perhaps it would be enough.

Anyway, then we get to the interesting bit:

> <off-topic>
> Perhaps as some additional food for thoughts, if I think about the form in
> which I could imagine to be a steward/maintainer for some aspect of Squeak
> it immediately comes to my mind that the first and faremost issue is that of
> enabling _others_ to be able to work on that same package. Since all of us
> have only a limited amount of time I think it is critical that more than one
> person is responsible for a particular package. One way in which I could
> imagine this, is by essentially giving each package its own update stream
> which is used for the developers of some package. In this case, any of the
> developers would be able to post and review changes that are done in this
> area, and "releases" mean only that the incremental updates are merged and
> put out as package at SM.
> 
> Of course, this requires trust in the developers working in a particular
> area, but this could then be the primary task of the Steward - to identify
> developers both interested and capable of working in this area. The
> essential model would be that the community (represented by the guides)
> hands their trust into the Steward and the Steward hands this trust to the
> group of developers involved. Whether the Steward herself hacks along with
> the developers is quite a different matter; she would simply be the person
> ultimately responsible for some package. So that feature requests, bug
> fixes, blames would rightfully go to the Steward and from there be relayed
> to the developers involved. Conceptually, SourceForge is not a bad model for
> this - it allows registered developers to participate in projects for which
> they need blessing by one of the admins of that project. In Squeak terms,
> the initial admin for one of these projects (packages) would be the steward
> and from there, more people could join in.

Right. I think all this sounds... well, "perfect" is the word popping
up. And this is also how I have "envisioned it" inside my head - though
I haven't written it down as nicely as Andreas has here. The point
anyway is that being a Steward does definitely not mean that it is a
oneman job. Delegation, delegation, delegation.

Accidentally KCP (SCG) seems to have adopted something similarly with
Alexandre Bergel as the appointed Steward/front man.

And btw, I like keeping toolchoices open as much as possible (for
example the package format agnosticism in SM) so IMHO a Steward is free
to pick and choose how a particular package is maintained (source
sharing, update stream, Monticello, DVS/CVS, autoslurped from a Swiki
;-) whatever makes that Steward happy).

The only thing we could try to standardize is how a bug/fix or enh is
"posted". IMHO a ChangeSet is still the most "capable" format and email
is a very simple transport (with a bunch of advantages).

We could very easily in SM1.1 add an email address field to a package
where bug reports/fixes/enhs are received. And if we adopt some very
simple standard of noting which package the post is for, we could easily
setup a new mailinglist on sqf that ONLY is used for this. For some time
I have been thinking that all those posts really could be on a separate
list.

Anyway, enough blabbering - I like Andreas "write up" and really think
this is the "expectation" we should place in a Steward and nothing more.
If nobody helps her doing the job then it isn't her fault - she only
agreed to hold the rudder, if the oarmen don't show up...

And btw, I think it is *VERY* important for the community - as we are
reshaping ourselves here - to take it a little bit slow. We *DO NOT*
want to end up in a situation where seasoned Squeakers don't feel like
participating anymore - we simply must make sure that we still are
*HAVING FUN*!


regards, Göran