Guaging community opinion (was Re: Complexity and starting over on the JVM)

Ken Causey ken at kencausey.com
Tue Feb 5 17:09:01 UTC 2008


On Tue, 2008-02-05 at 18:38 +0200, Igor Stasenko wrote:
> > As regards a given release, it seems to me the authority is fairly
> > clear: the release team and perhaps more specifically the release team
> > leader.  At that point of course the release team is in the position of
> > having to guage the community's reaction to a change.  And here is where
> > I think we have trouble in practice.  Our current methodology is to
> > listen to the vocal minority (those who actually go to the trouble to
> > post to squeak-dev or reply to the submitter).  My experience has been
> > that it is those who feel negatively about something that feel most
> > compelled to respond.  Correspondingly I strongly suspect there is a
> > significant minority (at least) who is quite happy with the idea but
> > either can't be bothered to respond or don't feel their opinion is
> > relevant; then there's another quite possibly larger group who have no
> > real opinion.
> >
> > Within this community I've come to feel that the only day to day
> > practical solution is to do it and then ask for forgiveness when it goes
> > all pear shaped (badly).  Of course when that happens it really helps
> > when it is something that can be readily reversed with no harm done.
> > And that's where it seems we have a problem because the current release
> > management schemes don't well-support removing something readily and in
> > such a way that few if any are inconvenienced.  I don't have a ready
> > solution to that, it is something I find myself thinking about more and
> > more.
> >
> > In the interim it seems to me that each release team has to make the
> > choice.  They can either take a chance, make a change simply based on
> > the vocal few and prepare for possible flames at a later date.  Or in
> > cases where it seems desirable, go to a little more trouble and call for
> > a semi-formal vote.  Clearly that's not something any of us want to do
> > every week.  But I don't think it would be that big of a deal to do it a
> > few times a year.  Details would need to be worked out but I think it
> > would not be all that difficult and would be easier each time we did it.
> >
> > I have other thoughts on this and related issues, but I find myself
> > getting more and more annoyed with long emails, and this one is already
> > over the threshold,
> >
> > Ken
> >
> There is a solution: enable multiple versions of same package in same
> image and keep track of package dependency.
> So, when you loading an updated package, all code which worked before,
> continues to work in same way as it was before.
> We need a way to be able developer to choose, what parts of system can
> use new version and what should use older version due to
> incompatibility reasons by simply checking dependencies and updating
> dependency links.

Certainly there are solutions, I've considered many and even discussed
them somewhat on #squeak.  But I personally I am tired of idea emails
without anything approaching an actual implementation.  I don't think
I'm alone in that.  So I'm not inclined to bring up a solution unless
it's one that either exists or can realistically be implemented in a
matter of hours.  Hence I suggest something that I know I can make work
readily, not necessarily the ideal solution.

> Also, this would help a lot in maintaining packages: a package author
> can easily keep track of his package dependencies, and may or may not
> wish to release his package with updated dependencies, which use
> latest versions of packages, his package depends from.
> 
> Of course, this is somewhat idealistic, and there is many caveats, but
> if done well, will allow us to mix things without fear that something
> will not work due to incompatibilities.

Ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080205/a94d0136/attachment.pgp


More information about the Squeak-dev mailing list