Squeakfoundation March 2003

squeakfoundation@lists.squeakfoundation.org

27 participants
66 discussions

3.6 release plans ( Was: re: 3.5 release timing )
by Brent Vukmer 11 Mar '03

11 Mar '03

In case the 3.6 release plan becomes a feature in the 3.5 release, here are few initial ideas for 3.6: --removing Balloon3D --removing Celeste --removing the "Worlds of Squeak" project The Welcome window in 3.6 could have "quick-install-from-SqueakMap" active links for each of the packages/projects that is removed. -----Original Message----- From: Craig Latta [mailto:craig.latta@netjam.org] Sent: Mon 3/10/2003 3:41 AM To: Doug Way Cc: Discussing the Squeak Foundation Subject: [Squeakfoundation]re: 3.5 release timing [snip] 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. :) [snip]

3 2

RE: [Squeakfoundation]RE: Your stewardship(s)
by Daniel Vainsencher 10 Mar '03

10 Mar '03

[API changes breaking compatibility] This will make having package releases much more important. Then users could ignore the problems by tracking a configuration that is compatible. The more breakage pain there is, the more conservative configuration builders will be. As you say, on the developers' side, conventions like private categories should be used, and frameword developers should start thinking of their APIs as semi-obligations, to be broken as rarely as possible. I think we can treat this whole subject lazily - we'll solve the problem when pain becomes common. I've personally had an API changed under me already (By PackageInfo), but I think it's still rare enough it's not worth addressing with Infrastructure or Rules. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Göran, > > > > 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. > > Honestly, I doubt it. The working style doesn't go that way. If you are a > user of some package you need to read the documentation first. That's fine > as far as it goes. But then you start screwing around and see that "perfect > method" which solves your problem immediately. And so you use it. There's > nothing in the _code_ that tells you "don't use me, I am private to that > package and using me means you're doomed to fail a couple of releases down > the road". The same on the other end. If you're a package developer you have > to constantly go to a different place and update your documentation. And > naturally, you will forget to do this because it's awkward. If you want to > solve this problem by documentation then this documentation must be > intrinsically linked to the code involved. And once you do that it _is_ > essentially a more declarative style of programming - even if you would put > it into comments (which I wouldn't). > > Also, the big issue with "all remote senders" which you were proposing is > not the fact that you can find those senders. Again, that's fine but the > problem is you can't _fix_ them. And that means you have to rely on the > implementors of that other package that they only use what you have declared > to be the "public API" which brings us back to the above issue. At this > point you could in fact say that everyone who uses any "private messages" to > that package be screwed but you can carefully phase out obsolete public > messages without the fear to break anything that has been written according > to your design (e.g., using public messages). > > The key issue is that both implementors and clients of a framework need to > be able to tell what interfaces exactly they can rely on. If you can't tell > this, handling large decentralized packages _will_ be a nightmare before > long. We cannot expect people to lock-step in the development if those > packages are individually developed, we cannot rely on having that "large > synchronized base" (e.g., monolithic image). If we want to allow evolution > then we must find a model of determining what we promise to support "long > term" (e.g., across minor versions) and what we don't. > > Cheers, > - Andreas > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

RE: Your stewardship(s)
by Andreas Raab 10 Mar '03

10 Mar '03

Hi Hannes, [Note: I've cross-posted this message to the SqF list (original message is quoted below) since some of the aspects in this message relate to the larger picture of stewards. Also, I might be wrong on various accounts and in this case a clarification might be helpful] > What do you think? I think that before I would agree to any such thing I need to have a _much_ clearer perspective on what the job of a steward entails. I barely withheld a heated reply to the threads involved, since to me, this looks very much like forcing people who have not agreed to do so into a position they may not want to be in. Let's be honest here: The "steward" _will_ be the maintainer of some package. Even though Daniel (I think it was him) wrote up that nice memo that the steward is simply a person with expertise in some area, I believe that the formal act of declaring someone to be the steward effectively makes that person the maintainer. After all, this person seems to have declared himself the manager of some particular area of the system, so who else would you go to? Not that I necessarily mind this, but a key issue is what we expect the steward to do in a world of decentralized packages. The way I see it, we'd probably want the steward to harvest fixes, goodies, enhancements along the way. We probably expect him to run tests if everything works allright in version XYZ of Squeak. We probably expect him to update packages regularly. All very good things - if you have the time for it. And the short answer is: I don't. I simply do not have the time to scan the postings at Squeak-Dev, I don't have the time to run regression tests, to test each and every individual part. At least not for the stuff you were proposing, and definitely not in an age of "montly releases". An important aspect in the maintenance debate is that Squeak does not lend itself easily to the style of decentralized development we're anticipating. 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 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. 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. Personally, I simply _use_ all of the packages you were referring to. My only interested at this point in maintenance is for the very lowest level of Balloon3D in which I would like to stay compatible between what's currently in Squeak and what is in Croquet (note: I did the Balloon3D and removal packages as a service to the community, not for myself; I don't need them to be removed, in fact I need them hardly at all). Other than that, I might post a fix, goodie, whatever to any of the other areas but fundamentally I am not interested in maintaining this or any further aspect at this point. So as far as the maintenance aspect is involved, my answer is "no" at this point. I simply cannot imagine spending enough time in any of these areas with a decentralized model of development. As far as being the "wise man" for some particular area is involved, there is simply no need to declare me the formal steward, because it wouldn't change anything - after all, if I see some question that I find the time to answer, I'll do this anyways. Given that, what would be the point in declaring me the "steward"? You get everything that I can handle already, and formally declaring me to be the "steward" can only mean that you want to assign new tasks to me, tasks for which I cannot guarantee that I can or want to handle them. Given the above, can you see any reason whatsoever why I should (or even want to) be declared a steward for the areas you are proposing?! <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. </off-topic> Cheers, - Andreas > -----Original Message----- > From: Hannes Hirzel [mailto:hannes.hirzel.squeaklist@bluewin.ch] > Sent: Saturday, March 08, 2003 5:02 PM > To: Andreas Raab > Cc: Doug Clapp; Brent Vukmer > Subject: Your stewardship(s) > > > > Dear Andreas > > May I draw your attention to the page > Stewards for Packages > http://minnow.cc.gatech.edu/squeak/3088 > > Is it OK that we put you on the list as the > steward for Balloon and Balloon3D. I think > that no discussion on the list is needed > because as the original author of this you > actually *are* the steward as well > unless you want to change that. > The same might apply for other "Squeak estates", > FFI for example. > > What do you think? > > Regards > Hannes >

2 3

RE: Your stewardship(s)
by Daniel Vainsencher 09 Mar '03

09 Mar '03

> Let's be honest here: The "steward" _will_ be the maintainer of some > package. Even though Daniel (I think it was him) wrote up that nice memo > that the steward is simply a person with expertise in some area, I believe > that the formal act of declaring someone to be the steward effectively makes > that person the maintainer. After all, this person seems to have declared > himself the manager of some particular area of the system, so who else would > you go to? The note I wrote lays out some reasonable expectations about people that take care of certain packages. The main point of the note, the first clause is - "The steward is nobodys bitch". It was there because I observed sometimes a habit for people to think of themselves as "consumers" that have a "right" to something or other from the "provider" of some package. This works at various levels, from the Guides to maintainers of a specific package. I think the most important thing to remember here is that everyone's here for fun, and the people that contribute are most used to seeing this as active fun. So the question is not "can we call them something formal so we can make various demands of them", but rather, "how can we make things more comfortable for them, so they'll continue to play in this sandbox". Which is an important reason why I wrote that note to clarify expectations, so Stewards don't need to constantly do so. Which is also an important reason I didn't make a link between stewardship and specific people - it should be a role people decide to slip into and out of, not something to make a fuss about. I think what Hannes and co are really trying to do is a. document who the wise men are, so that someone new has a way to find them. b. give control to those that earned it. But control is also a burden, so be gentle about it. Or don't do it at all, just let it emerge (Do we need to declare Anthony steward of the compiler? I think that might just screw it up. He's doing wonderful work without any such prodding). [Expectations from package maintainers] I think you present a very specific scenario for the "centralized maintainer". Someone other than the main maintainer can easily be the one to run regressions. Yet another can make the first cut about proposed fixes. The scenario you describe later, of work distributed among a group, with one "wise old man" sound much healthier to me. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Hannes, > > [Note: I've cross-posted this message to the SqF list (original message is > quoted below) since some of the aspects in this message relate to the larger > picture of stewards. Also, I might be wrong on various accounts and in this > case a clarification might be helpful] > > > What do you think? > > I think that before I would agree to any such thing I need to have a _much_ > clearer perspective on what the job of a steward entails. I barely withheld > a heated reply to the threads involved, since to me, this looks very much > like forcing people who have not agreed to do so into a position they may > not want to be in. > > Let's be honest here: The "steward" _will_ be the maintainer of some > package. Even though Daniel (I think it was him) wrote up that nice memo > that the steward is simply a person with expertise in some area, I believe > that the formal act of declaring someone to be the steward effectively makes > that person the maintainer. After all, this person seems to have declared > himself the manager of some particular area of the system, so who else would > you go to? > > Not that I necessarily mind this, but a key issue is what we expect the > steward to do in a world of decentralized packages. The way I see it, we'd > probably want the steward to harvest fixes, goodies, enhancements along the > way. We probably expect him to run tests if everything works allright in > version XYZ of Squeak. We probably expect him to update packages regularly. > All very good things - if you have the time for it. And the short answer is: > I don't. I simply do not have the time to scan the postings at Squeak-Dev, I > don't have the time to run regression tests, to test each and every > individual part. At least not for the stuff you were proposing, and > definitely not in an age of "montly releases". > > An important aspect in the maintenance debate is that Squeak does not lend > itself easily to the style of decentralized development we're anticipating. > 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 > 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. > 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. > > Personally, I simply _use_ all of the packages you were referring to. My > only interested at this point in maintenance is for the very lowest level of > Balloon3D in which I would like to stay compatible between what's currently > in Squeak and what is in Croquet (note: I did the Balloon3D and removal > packages as a service to the community, not for myself; I don't need them to > be removed, in fact I need them hardly at all). Other than that, I might > post a fix, goodie, whatever to any of the other areas but fundamentally I > am not interested in maintaining this or any further aspect at this point. > > So as far as the maintenance aspect is involved, my answer is "no" at this > point. I simply cannot imagine spending enough time in any of these areas > with a decentralized model of development. As far as being the "wise man" > for some particular area is involved, there is simply no need to declare me > the formal steward, because it wouldn't change anything - after all, if I > see some question that I find the time to answer, I'll do this anyways. > Given that, what would be the point in declaring me the "steward"? You get > everything that I can handle already, and formally declaring me to be the > "steward" can only mean that you want to assign new tasks to me, tasks for > which I cannot guarantee that I can or want to handle them. > > Given the above, can you see any reason whatsoever why I should (or even > want to) be declared a steward for the areas you are proposing?! > > <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. > </off-topic> > > Cheers, > - Andreas > > > -----Original Message----- > > From: Hannes Hirzel [mailto:hannes.hirzel.squeaklist@bluewin.ch] > > Sent: Saturday, March 08, 2003 5:02 PM > > To: Andreas Raab > > Cc: Doug Clapp; Brent Vukmer > > Subject: Your stewardship(s) > > > > > > > > Dear Andreas > > > > May I draw your attention to the page > > Stewards for Packages > > http://minnow.cc.gatech.edu/squeak/3088 > > > > Is it OK that we put you on the list as the > > steward for Balloon and Balloon3D. I think > > that no discussion on the list is needed > > because as the original author of this you > > actually *are* the steward as well > > unless you want to change that. > > The same might apply for other "Squeak estates", > > FFI for example. > > > > What do you think? > > > > Regards > > Hannes > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4 bugs?)
by Daniel Vainsencher 09 Mar '03

09 Mar '03

The reason I see Accufonts as a step forward is that Apple is currently the only player we're concerned about. Doug Easterbrook isn't. He's easy to please and doesn't have a legal interest in Squeak. Since is simplifies things for Apple, Accufonts is an improvement. Long term, I agree with you. Daniel Cees de Groot <cg(a)cdegroot.com> wrote: > > --Boundary_(ID_l363gpxol2YRQ4TbPQ5Egg) > Content-type: multipart/signed; boundary="=-N3o9iVnCCoxuLNAOBGSN"; > protocol="application/pgp-signature"; micalg=pgp-sha1 > > > --=-N3o9iVnCCoxuLNAOBGSN > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > On Sat, 2003-03-08 at 08:08, Daniel Vainsencher wrote: > > I agree with everything you said. About Accufonts, I think it depends on > > what Cees/Andrew can tell us about any discussions with Apple.=20 > I haven't heard anything back yet.=20 > > Just to make it abundantly clear: Accufonts replacements would be a > token gesture to Apple, it wouldn't do anything to make Squeak more free > because the Accufonts license has exactly the same problem as the Apple > fonts license. > > > I would really love to know that Andrew and Cees are talking, and we're > > getting Andrew's best (non-official) advice about how to go about this. > >=20 > I've given up mailing to Andrew (and Dan) on SqF/Licensing issues last > summer, after never getting responses from either one on repeated > requests. So I'm at the moment 'singlehandedly' tackling discussions > with Apple. > > > --=-N3o9iVnCCoxuLNAOBGSN > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQA+aftT8wOTf+CYnosRAkAvAJ9zAEk9imHaz09MWPRdCu3Qww0YsQCgqKqq > bCwwDWOtz2bvk3F7jcBkGAQ= > =Vxia > -----END PGP SIGNATURE----- > > --=-N3o9iVnCCoxuLNAOBGSN-- > > > --Boundary_(ID_l363gpxol2YRQ4TbPQ5Egg) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7BIT > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > --Boundary_(ID_l363gpxol2YRQ4TbPQ5Egg)--

1 0

3.4 press release
by Cees de Groot 08 Mar '03

08 Mar '03

Hi, I had a bit less time than I expected tonight, so I wasn't able to give the attention I wanted to the 3.4 press release. Nevertheless, I dare to ask you to take a look at this draft: http://swiki.squeakfoundation.org/squeakfoundation/95 and comment on it. The last paragraph is destined to become the standard Squeak blurb for press releases, so I'd appreciate some extra attention to detail here. Regards, Cees h.t. External Relations Volunteer

5 7

Re: [Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4 bugs?)
by Daniel Vainsencher 08 Mar '03

08 Mar '03

[about one quick fixes release] Doug said: > That does make some sense. A "very good" release might be a good start > before getting down to splitting up the image and other work, as > opposed to a more average release. A reference release of sorts. And > good PR, I suppose. > > It would delay the "getting down to splitting up the image" by at least > a month, though. People are posting "Remove <whatever>" packages, though slowly. I think I can help people to speed up and focus this process independent of the release schedule, as long as the fixes made do not break refactorings by including too many things. So as long as the fixes release is focused on the important stuff, I see no conflict. When we start 3.6, we'll have a few more removals ready to go. > And I'm not sure it's *really* that important. So > I'm still on the fence, awaiting a few more opinions. Yup, I'd like to hear more too, but keeping in mind that - > But we do need to decide on the 3.5 release timing very soon... Daniel

2 1

[DOCS] Swiki as a reference manual? (was: RE: [Squeakfoundation]Stewards and Squeak Packages)
by Hannes Hirzel 07 Mar '03

07 Mar '03

goran.hultgren(a)bluefish.se wrote: [snip] > ..and I also don't like to have the "reference manual" > of Squeak in a Swiki - I want that *inside Squeak*. You know - the > classic problem of keeping two different places in synch. Why would > someone remember to edit this page when a class is added or removed? Having a reference manual inside Squeak is our mid-term goal. But at the moemtn this procedural issue about keeping class comments in synch is surely not our main problem. The main problem is having comments in the first place at all. Compared to the considerable amount of work writing a good class comment (research, writing, checking) the task of comparing a class comment in Squeak with a possible better version on the swiki is a piece of cake. Of course it would be very handy if there was a button in the class browser withing Squeak labeled 'get comment from SqueakMap' and another one 'upload comment to SqueakMap'. The comments should then be in the Squeak Text Hypertext format. Such a tool would perhaps (perhaps!) motivated people to write comments in the first place. -- Hannes

2 1

[DOCS] about swiki updating (was RE: [Squeakfoundation]Stewards and Squeak Packages)
by Hannes Hirzel 07 Mar '03

07 Mar '03

goran.hultgren(a)bluefish.se wrote: > I am just tired of redundant swiki pages forgotten by the author that > aren't up to date. The member of the documentation team agree with this: For this reason we are going through these pages. In specific cases we contact the original author and ask him for an update if we can't do it ourselves. We mark some of the pages as "outdated" and the content of some of them is just deleted and a mark *recyleMe* is added. Anybody who has done swiki pages in the past and hasn't updated them recently is welcomed to help with this updating effort. -- Hannes P.S. And: the swiki contains a lot of useful content.

2 1

RE: [Squeakfoundation]Stewards and Squeak Packages
by Brent Vukmer 07 Mar '03

07 Mar '03

Goran, Cees -- Thanks for taking a look! Your edits are very helpful. I assumed pretty much everything I wrote on those 3 pages would be heavily edited :) I just wanted to get the ball rolling by creating at least a 0.1 draft of the Swiki pages... Goran: 1. Definition of "Core packages" --No argument. I tried to indicate that talking about "core" packages in 3.4 is pretty ambigous. --I liked Cees's note 2. Lists of classes/categories --These lists were intended to be a throw-away first draft, as I tried to indicate ----I hope/expect that the community will edit those pages and make 'em more accurate and helpful --It was helpful to me, at least, to get an initial idea of the possible package boundaries 3. Becoming a steward --I tried to indicate that becoming a Steward is not automatic by *any means* ( see http://minnow.cc.gatech.edu/squeak/3090 ) --Thanks for editing http://minnow.cc.gatech.edu/squeak/3070 Are the MCP the collective Steward for Morphic, yet? Ditto KCP for the Kernel? Thanks, Brent -----Original Message----- From: goran.hultgren(a)bluefish.se [mailto:goran.hultgren@bluefish.se] Sent: Thursday, March 06, 2003 4:22 PM To: Discussing the Squeak Foundation Cc: Squeak-Dev (E-mail) Subject: Re: [Squeakfoundation]Stewards and Squeak Packages Hi! "Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > Please review the following Swiki pages: > "Core Packages" ( http://minnow.cc.gatech.edu/squeak/3084 ) > "3.4 Core Packages" ( http://minnow.cc.gatech.edu/squeak/3085 ) > "Stewards for Core Packages" ( http://minnow.cc.gatech.edu/squeak/3088 ) I looked them over and wrote two comments. Well, one on "Core packages" and one somewhere else... Anyway, in short: 1. I disagree with the definition of "core package". Can be debated of course. 2. I am a bit uneasy of these pages with long lists of classes/categories. Are they really going to be kept updated? Consider me skeptic. 3. I like the "Stewards" stuff. And Squeak estate is also a nice pun with some meaning. But we may take it a bit easy on the signing up part. I mean - we shouldn't just let "anyone" sign up as a Steward for a core package without due discussion and some form of agreement on these lists. I know we don't have a formal process or anything like that - but still. you can't just grab something and call yourself a Steward. If there is anything we Guides should take responsibility for then it is to steer this process of dishing out Stewardships. > I think that the "Stewards for Core Packages" page is a decent beginning for a Stewards sign-up sheet. Yes, but I took the liberty of typing in a few remarks according to what I wrote above. Ok? regards, Göran

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation March 2003