Packages March 2005

packages@lists.squeakfoundation.org

10 participants
21 discussions

Re: proposal for starting work on partitioning
by Doug Way 04 Apr '05

04 Apr '05

Hi all. I'm the Coordinator assigned to this team... sorry I haven't actively participated until now, I just finished catching up with the list. (I know Goran is also participating, but I definitely need to do some coordinating here to make sure this work gets incorporated into 3.9.) > Hi! > > Avi Bryant <avi.bryant(a)gmail.com> wrote: > > On Tue, 8 Mar 2005 10:45:11 +0100, goran.krampe(a)bluefish.se > > <goran.krampe(a)bluefish.se> wrote: > > > > > Again, this presumes that we are focused on splitting. I would > very much > > > want us to stake out regardless of split work. In other words, let > us > > > throw a rough PI list on the Swiki (as you say) and let people > sign up > > > interest regardless if they immediately intend to hack on > splitting. > > > > Sure, that's fine - if people would also like to declare interest in > > maintaining a package, as well as in doing immediate splitting work, > > that's clearly good information to record. > > Ok, goodie. :) Sounds good. Although looking at the swiki page: http://minnow.cc.gatech.edu/squeak/5641 I see that most of the listed packages have still not been assigned. I wonder if we might have more luck making the initial package list even more coarse, and trying to get more than one maintainer for each. E.g. just have one Tools package with a few maintainers, instead of trying to find a maintainer each for Tools-Browser, Tools-Changes, etc. Well, when talking about coarse vs fine-grained partitioning, I guess there are a few factors mixed into this... assigning maintainers, but also whether the subpackages are interrelated. But even with something like the "System" packages, which are sort of a grab-bag of random stuff, I wonder if we might be better off treating them as one big package for now, and trying to get someone who might prefer to support one section, to sign on instead as a co-maintainer for the whole thing. Also, it would probably help a bit to beg on squeak-dev for more volunteers. :) > > I happen to disagree with > > you about priorities: the most important thing, for me, is to enable > > the packages to be independently maintainable; only once that's > > possible, and once we've had a little bit of experience doing things > > that way, are real maintainers likely to emerge (or, for some > > packages, they won't - but that's interesting to know too). So by > all > > Possibly. But I am betting we can get people signing up even though the > pieces they are interested in are intermingled. :) Well, I think both tasks are potentially difficult... doing the splitting but also finding maintainers for everything. I'd say let's get going with both tasks. > > means let's start gathering information about who might want to > > Steward what, but I won't personally feel any real sense of progress > > until packages start taking concrete, accurate shape inside the > image. > > Well, I am just cautious given earlier attempts that have stalled. :) > And I also think that even intertwined packages would benefit from > having clear assigned maintainers/stewards. > > > There's no real need to argue about this, since both can happen in > > parallel. > > Exactly, no argument whatsoever. :) Right. :) > > But is anyone else interested in either of those things? > > The list as a whole has been pretty quiet. Maybe we're covering the > > wrong topics? > > Well, I am all with you - but I agree it has been quiet. Well, we may want to go back to squeak-dev to ask for "help"... there are probably people interested in specific packages who may not be following this (Packages) list closely. > > > A special stream is of course a way, but what are the reasons for > not > > > using the 3.9 alpha stream? If this is in order to get a quicker > > > turnaround I think we instead could put one person as a special > reviewer > > > and then that person can feed it straight into 3.9alpha. Like Doug > > > (being release manager) or you with the trust of Doug or whatever. > > > > Well, I'm guessing we'll be doing some things (like categorizing huge > > swaths of methods as "*orphaned") that wouldn't be great for mass > > consumption; I'd feel better if we were in a private stream while > > starting this work, anyway. > > Ok, I agree. Hrrmmm, I also think that just using the 3.9alpha stream would make more sense. Give Avi direct access to the update stream, being one of the team leaders. (The Morphic Splitters team leader should also have access.) I was hoping to have a more open/optimistic approach to the update stream with 3.9, with more people having access. (Has the private stream started up yet?) Having a bunch of recategorizing going on in the main update stream might not necessarily be a big deal, the same code is still there, it's just the method & class categories changing. (Would there be that many methods changing to "*orphaned"? I'd think when in doubt, you'd leave them in current package (that the class is defined in) until you knew where they were going to go. In any case, moving stuff to *orphaned seems relatively low priority, and fairly harmless.) Basically, I think there is more danger that the effort will stall if a private stream is used, because then there will be a big merging effort required at the end. In fact, if everyone can see progress being made in the public stream, that might encourage more people to contribute. > So, then unless someone shouts Bloody Murder within a few hours :) then > I would think we should move ahead with yourt plan - create the Swiki > page, create a first shot at a list of PIs for current 3.9alpha and ask > squeak-dev for people stepping forward for either split work or > stewardship and sign up. Ah ok, we can ask for more help then. :) By the way, I agree with moving forward with PI as the format. > When we tried this the last time we ended up with trying to change the > categories etc, and got stalled doing that - so my advice would be > either to: > a) Don't bother. Just throw together a list of PIs to begin > with given > the current 3.9alpha. > b) Sit down yourself and whip together a changeset first and > post that > to your new updatestream. Don't bother discussing it here - just go. :) > > Go Avi, go! Is there anything else we need to do to help this move forward? Will most of the PI managing/recategorizing be done with the Monticello tools? (We've discussed adding MC to Basic as part of this.) Also, we should add Ned's PI extras to Basic (the 3.9 stream). - Doug

6 9

Re: Dan's analysis thingy
by Dan Ingalls 21 Mar '05

21 Mar '05

>After filing in the patch Dan just posted on squeak-dev, I ran: > >etoysRemovals _ Smalltalk reportClassAndMethodRemovalsFor: ((PackageInfo named: 'EToys') classes collect: [:each | each name]). ... Hi, Cees - Thanks for actually taking the trouble to try this out! Just to complete the archaeological dig, check out SystemDictionary>>computeImageSegmentation ;-). It's out of date, but it shows how you can do a lot of different packaging experiments at once to save time. While I haven't tried it, I think Daniel's Mudpie may help with determining effective root sets, after which my "differencing" scheme is pretty effective, as you discovered. - Dan

2 1

Re: New Squeak Management Structure
by goran.krampe＠bluefish.se 21 Mar '05

21 Mar '05

Hi! John Pfersich <jp1660(a)att.net> wrote: > I haven't been paying any attention for a while to the new structure > that Goran has been promoting. Mmm, are you referring to "The Coordinators"? > I find that lately its been really > hard to follow the thread because the subjects do not reflect the > topic being discussed. > Is there a place that it's down on paper? Well, what we (The Coordinators) have currently is this readonly swiki: http://anakin.bluefish.se/castaways On that swiki we have a few important things, first the reports (a new one is probably due soon): http://anakin.bluefish.se/castaways/8 ...and the structure of Teams: http://anakin.bluefish.se/castaways/6 We will try to write down a single page about how we are working and how we are organized, I agree that a concise page on that is needed. The Team-page has a "manual" for how the Teams work though. > I had signed up for the maintenance of the Network section under Task > Force November Revolution (TFNR). Will that change? Change? Well, it is great you signed up - and nothing has really changed - but hopefully this time we are getting this show on the road. The TFNR thing got stalled/died and btw, this is the swiki page for it: http://minnow.cc.gatech.edu/squeak/661 The "Packages" team led by Avi has taken over that ball (TFNR) and Avi has recently created a new list (easiest to start from scratch) for people to sign up on parts of the image: http://minnow.cc.gatech.edu/squeak/5641 The pages produced under TFNR still has value, and let us use those pages to: - Find people that expressed interest earlier to do Stewarding - Use some of the results, like this for example: http://minnow.cc.gatech.edu/squeak/3534) I am crossposting this to the packages list btw, and if you are interested in TFNR/Packages etc, as I presume you are - join that list/Team which you find at: http://discuss.squeakfoundation.org > I'm liking this over BFAV just because it's easier to see the Network > stuff that I'm trying to maintain. > I do have a question about how the stuff gets harvested (or whatever > the term is now). How does that happen? A few notes: 1. The Janitors team led by Ken Causey is handling how the harvesting process is migrating into the future. In the short term this means how we are moving over to Mantis and to deal with bug reports and fixes using that. 2. The Packages team (led by Avi) is figuring out how to partition the image (as per TFNR) and how we will live in that new brave world. How to deal with bugs/fixes in a partitioned image is still a somewhat open question - but the Janitors team is creating a model where we can use Mantis for that too (where you can select/filter based on "package" etc). Since I am reopening my work on SM now I also have a few ideas on how to help this - for example by adding a field with an optional email address for each package that can collect fixes/reports. STTCPW and all that! :) Also, 3.9 will probably include PackageInfo-Extras which has brand new changeset-splitting-based-on-PIs code in it, and some nifty menu choices in the changesorters for that! 3. The v3.9 team led by Doug Way has the final say on what goes on with version 3.9 that is sheduled for june/july. Since 3.8 is getting realeased Any Day Now (tm), 3.9 is the next frontier and one of the main components of 3.9 will be the result of the Packages team. Read more here: http://minnow.cc.gatech.edu/squeak/5645 Did this answer the more general questions? regards, Göran

1 0

Feedback
by goran.krampe＠bluefish.se 18 Mar '05

18 Mar '05

Hi guys! Evidently it is dangerous not being online for a weekend. :) Anyway, I have read all posts to this list and would like to make some swift comments first: 1. If I read you right Avi, you suggest us sticking with PI as it stands today. I tend to agree, we will learn a lot through this project and we can always migrate to something like Alexandre's recent work afterwards. PI is being depended upon quite a lot right now so sticking to it, disregarding its warts, is the way to go at this time - we all know how it works and the tools work with it. Also, Ned has recently posted a "power pack" for PI including some split-changesets-based-on-PIs that I and he wrote independently. I strongly urge us to perhaps make that stuff an official package in Basic and get it in. :) Or just merge it into whatever places it affects (ChangeSorters etc, the PackageInfo package). Just as long as we "gear up" properly for our quest. :) 2. Your initial post didn't clearly express the idea that we can indeed "stake out" the image without having to actually "break out" parts of it. I think that piece of the puzzle is important. The TFNR idea was precisely that, meaning that it is better to have a tangled mess that is staked out, than to have a tangled mess. :) So I would like for you to clarify your view on that. In other words - I would like for us to make a 100% stake out *first* (it can be made quite quick if we don't get too granular - let the PIs divide themselves later if their Stewards feel the need), and then *after* that start breaking out stuff. And sure, we may end up with a few "largish" PIs and perhaps even a "what is left in the bucket"-PI but so be it, then we at least have a *fully covered* image AND using the existing field in SM we can map each such PI to an SM package and thus we know *who* stewards it and what emails they have etc. And just by accident we can then (given Ned's power pack) use the changeset splitting mechanism to easily feed multi-package-covering-changesets to the maintainers. Ok, I reread your post and perhaps you *do* indeed mean this - sorry if I misunderstood. :) 3. I intend to focus on SM now, it seems that we have managed to get ourselves organized pretty good and we do have a plan for the next few months in place. So *my* main Team is *this* team and my main job in this team is SM. :) And regarding the future of SM: 1. Lex mentions a few needs currently not being addressed by SM. One is the ability to have "private" repos - or in other words to decentralize SM into multiple connected servers in some way. This has been in my plan for a long time but I have postponed it because I didn't want to limit the model because of it. I am all ears for making this happen, but not before dependencies or a few other good things. Then, when the model looks somewhat "complete" we can again try to fogure out how we distribute it. :) And also, Avi has a good point in that SqueakSource etc fills a "developer space" that SM doesn't - so the need is less today than it was before SqueakSource/Monticello I guess. 2. The ability to be able to create a "loose package" that can be sent to someone etc, is part of the above. I just want to say that the model in SM is quite interconnected, so these things aren't trivial to do if we want to keep some of the current features of SM. But again, I am interested in solving this somehow too. 3. Dependencies. I have said it before and don't want to sound like a broken record :), but I do have a working implementation in my dev image. I need to fix a few things and put a few UIs on it. I also should describe the implementation so that you can give feedback. 4. Universes. I intend to look into Lex's code again more carefully and try to figure out how to either: a) Make it work "with" SM. But this is only interesting if Lex or someone else wants to continue maintaining Universes and nor merging it with SM. b) Merge the concepts and mechanisms with SM so that the sum is greater than the parts. Phew. Ok, now I read the final post from Avi again and... well, I still wonder a bit about the "stake out first" contra "break out". But anyway, a great start guys! regards, Göran

3 16

local SqueakMap's (was Re: Feedback)
by Lex Spoon 16 Mar '05

16 Mar '05

goran.krampe(a)bluefish.se wrote: > > Clashes seem like a fine strategies as well. Notice that they also seem > > to happen whenever you do an "update" from a more public server; changes > > that have been committed locally, may turn out to clash with something > > that happened upstream. > > Well, in general systems yes :) but in SM, no, not really. Because > locally you will only modify your own account - modifying other parts of > the map is a general "no, no". If you do that, then you are on your own > IMHO. :) Okay, if it helps then this constraint does not seem too onerous. > > Going the clashes route, it seems like the > > model now needs to have support for "stuff killed off by an update from > > upstream", plus some way for the local users to fix up the situation. > > Yes. Typical issues when committing are: > > - You created a package (or some other artifact with unique names) with > a name that already exists. > - Your SMObjects refer to other SMObjects that do not exist anymore > (categories could be removed, package releases also etc, etc) > > ...but without giving it tons of thought I do think the above two things > are mostly it. Okay. Just wait until you try to write a "merge" method. :) You'll find the cases in a hurry! > > > I guess another general approach, is to try and rename the UUID's > > locally, in order to undo the conflict. I don't know if this is doable > > or not. > > Hmmm. Not sure I grok that. :) Bah, let me write it more carefully. Suppose you add a package "Foo", and someone else adds a package "Foo" upstream. One solution is that the tool automatically renames the local Foo to be Foo2 in order to avoid the conflict. It also works at the ID level. If you make a package with ID 1234, and the upstream server also used ID 1234, then change your package to use 5678 and update all references to your package to use the new ID. > > And (heck) a fourth, is that you change from UUID's to server-unique > > ID's. So when you refer to an ID, you have to know which server it > > pertains to. [...] > Which means that, perhaps I didn't write it, but the server marker in > each SMObject makes sure it has a "home server" in the server "tree", [...] Cool, this home marker you describe seems like a fine way to implement this fourth strategy. An ID does not have to just be a number; it could be a tuple of (home-server, number). Then, even if two different servers use number 1234, it is okay, because the full identifiers will have different home servers. > One way of making mixins simpler might be to restrict mixins to be a > leaf thing. I mean, the servers are all in a tree like I describe but > the leaf (localhost) could possibly use mixins and take the heat of that > locally. But again, I would gladly wait with mixins until later. Yes, that would be workable if it helps. It's nicer if servers can pull from multiple locations as well, but if that's not possible, it could always be placed in the map's top-level comment, just like dependencies are described in pacakages on SqueakMap of today. Is it a mixed blessing to push it down to the leaves, though? It seems like once you have accepted the pain of dealing with conflicts from upstream, it might only a small additional amount of pain to deal with conflicts from multiple upstream pointers? Lex

1 0

Fwd: Re: Your MorphicSplitters packages
by Dan Ingalls 15 Mar '05

15 Mar '05

[cross-posted to packages discussion] >Date: Tue, 15 Mar 2005 15:31:25 -0800 >To: morphic-splitters(a)discuss.squeakfoundation.org >From: Dan Ingalls <Dan(a)squeakland.org> >Subject: Re: Your MorphicSplitters packages > >Hi, Juan, Cees and all - > >> > > Ps: I like what I have seen of your work. And I will soon move another >> > > big bunch of methods. I believe we are on the right track with this. > >I apologize for being busy with other things. Looks like you're making great progress. > >I just want to make sure you're getting help as much help from tools as possible. As I reported, years ago when I wrote it, > >>For example, the expression >> Smalltalk reportClassAndMethodRemovalsFor: #(Celeste Scamper MailMessage) >>reports 63 classes and 155 other messages that can be removed. > >In a way the biggest accomplishment here was *automatically* identifying 155 extension methods (and, of course, filing them out with the package if desired). > >If any of this doesn't still work, I'll happily do the necessary maintenance. > > - Dan

1 0

Re: Feedback
by Lex Spoon 14 Mar '05

14 Mar '05

I don't have a specific proposal on what to do about SqueakMap and Universes, but my meta-response is: we should use whatever works for the goals we want to solve. I'm hoping the goals can be sorted out on this list, and then the technology options can be analyzed. All I meant in the previous post is that we have workable technology right now, and so surely we should use it until something better comes along. A few thoughts. First, we should not ignore the strategy where SqueakMap is a place to find stuff about the *whole* squeak community, while Universes is used to organize the development of sets of packages. It would be much like FreshMeat versus APT in the Unix world. Ideally, all these tools (including SqueakSource and SqueakPeople) would communicate with each other to try and reduce the clutter that developers deal with. Also, I am not sure how compatible it is to have a server that knows everything, but a package-set tool which wants to allow private local servers. These seem like goals which will be hard to solve with a single tool. Although, it sounds like you are giving it a go, Goran. If it works, then that's great! I think we should keep in mind that Universes does address a lot of our needs, even though it does not have room (that I can figure out) to include a registry for the entire Squeak project. This reemphasizes, I think, the idea that maybe there should be two separate tools. Finally, even if the individual programs are different, it could well be that SqueakMap becomes a project that includes two different kinds of tools in it. That's a wonderful result for me. I always have a large pile of interesting computer projects to work on, and thus I'm always happy for an excuse to set one aside or pass it on to someone else. I have been pushing this universes stuff because it seemed that people could not grok it without having a prototype to play with. Avi, I agree that it makes sense to have some kind of public registry of universes. I wish Debian had that, but the powers that be don't seem to emphasize that there are other Debian packages in the world other than those in the official channels. -Lex

3 3

Re: user types
by Avi Bryant 09 Mar '05

09 Mar '05

On Sat, 5 Mar 2005 16:59:46 -0400, Lex Spoon <lex(a)cc.gatech.edu> wrote: > It means that version 1 may well not work the way it was > expected, and thus that we need to be prepared to watch how the tools > actually get used and adapt to what people want. Some features, > painfully, might not turn out to be useful at all. We should be careful > not to get so attached to our theories, that we refuse to recognize what > the users are actually doing. Hear, hear. > There should be a way to have local repositories, so that the Scratch > group can make progress. One implication of this is that identifiers of > all kinds are going to have conflicts between the local repositories and > the well-known global repositories. > > It looks like mixin repositories would be useful, in order to support HP > Lab's internal packages. > > Along these lines, it would be ideal if it is possible to manage a > package manually, without reference to a repository. It should be > possible for one Squeaker to send a newly created package file to the > Squeaker sitting beside them on another computer, without invoking lots > of infrastructure. One distinction that I make that I'm not sure if you're making here is between development repositories and release repositories: between, for example, SqueakSource and SqueakMap. My needs in the role of the developer of a package are very different from my needs in the role of a user of a package. The way we've been operating so far is to have one central release repository, and many scattered development repositories. This isn't because anyone's enforced that approach, it just seems to be what people do: there are lots of local installations of SqueakSource, but I don't know of any local installations of SqueakMap. This makes sense, though; I would imagine that inside something like HP Labs, or netstyle, or impara, people mostly want to access packages in the developer role - they may not themselves be a developer on the package, but they'll be familiar enough with it to want to be aware of the various branches, the bleeding edge versions, the commit logs, and so on, and they want to be able to make and commit changes if necessary. It's only when sharing packages between organizations that you want all of that messy development stuff to be hidden behind simple version numbers and release notes. Yes, this is an oversimplification - an organization or group of collaborating organizations might get big enough that one internal group really does just want to access the releases from another internal group's packages. But I'm not sure it's an oversimplification that's really become a pain point yet. Those inside big, Squeak-using organizations, speak up! (Which raises an interesting tangential question: what's the biggest team using Squeak? The projects I've worked on are all in the 2-5 developers range). It would certainly make things simpler if we turned out not to need decentralized release repositories (and we already have a model for decentralized development repositories). But is it just that people are working around a hole in the toolspace? What I'm certain that we do need, even if we have a centralized release repository, is a way to have different views of it, controlled by different groups. A project like Scratch may not need to make a release available behind its firewall, but they will want to control which released packages and package versions are visible (by default) to Scratch users. Avi

3 3

Re: Feedback
by Lex Spoon 09 Mar '05

09 Mar '05

"Lex Spoon" <lex(a)cc.gatech.edu> wrote: > For the record, Universes is under maintenance and in use, and (no > surprise) it achieves all of the properties I mentioned in my opening > email. Crud, I hit send too fast. There are other properties that would be nice, to be sure, and we'll get there. -Lex

1 0

partitioning a moving target
by Avi Bryant 09 Mar '05

09 Mar '05

Should we be doing our partioning work based on Squeak 3.8 or 3.9a? Either way we have to deal with moving target issues; the question is whether we want to have a stable base while we do the bulk of the work, and then have to update to match 3.9, or whether we want to have the ground constantly pulled out from beneath us by the new updates in the 3.9a stream. Or is there some third option? Avi

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Packages March 2005