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
|