This talk of paying worries me. I see many open source projects that do very well with very little funding. I see many people participating in Squeak -- after all, just look how many ENH's we have. :) Surely there is a way to channel all this energy, especially given the large number of successful OS projects in the universe?
I fear that if we use money to prop up our current situation, we will just keep on doing things in a sub-optimal way. Surely we can figure out what the other guys do, that we do not? I do not oppose spending money in general on Squeak; I simply worry about trying to use it to speed up business as usual.
- Packaging. Packaging. Packaging. Did I mention Packaging? You will never
get enough manpower together to manage a monolithic image. Not unless you want to call yourself Java or something. I'm quite sure that as soon as the core is of a managable proportion, a lot of the backlog will vanish because the load will be distributed; if someone doesn't take up 'his' bugs, just kill them. If a package is not maintained and starts to exhibit bit rot problems, junk it.
Here here!! You are all tired of hearing it, but Debian does *fabulously* on very little money. 8000+ packages and 900+ developers. A major part of Debian, I think, is that everything is divided into packages and each package has a maintainer. Un-maintained packages are gradually marginalized and then removed from the distribution. When there is a bug report, it's easy to see who is responsible, and it's easy for the responsible person to become aware of it.
Are there any bugs posted against Chuck right now on Mantis? I have no idea. And what about Nebraska, which is still in the image? Eek. In Debian, I have exactly two bug reports open.
- A good portal where new members, as someone else explained here, are
presented with information about what constitutes good behavior; if more people get invited to the harvesting process, AND the scope decreases, we can go a long way towards making the maintenance manageable.
I don't know if it needs to be the front page, but I certainly agree that our current situation is very confusing. Further, it's tough to contribute. As I've posted before, opening BFAV and looking at random enh's and fix's is quite hard, and feels wasteful of my time.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-June/078737.html
It has occured to me to sign up as the Nebraska maintainer, but I don't even know how. I could figure it out, I guess, and I will eventually, but shouldn't this be very easy? Someone volunteered for EToys not too long ago (Ned I think), and it was actually *overlooked* because they merely posted it to the list.
A SqueakSource-like portal would rock, but a great start would be for someone to go through the swiki and really organize all the pages about our processes, whatever they are. Start from here:
"How to contribute to Squeak" http://minnow.cc.gatech.edu/squeak/3279
This page is honestly not bad, but it bothers me that "maintain a package" and "assume responsibility for a segment of Squeak" are not listed on this page. I know its in the swiki somewhere...
I'm putting up the devil's advocate hat here, it'd be nice if more people could earn their money with Squeak, especially if they'd develop Squeak rather then develop in Squeak, but I'm not convinced that it is this community's most pressing problem at the moment.
Well, I'd like to see it, but again, I want us to be extremely careful about where we interject money. It will prop up one part, but if it is failing on its own, is it really something we want to spend money on?
I say we pay people to make Squeak books. :)
-Lex
Hi all!
A few short reactions without blabbering:
1. Regarding keeping up with all the work (harvesting primarily). Yes, Cees is right. Packaging, packaging. This is TFNR all over, and we really need to move forward with that. It is nice to see that more and more people are getting convinced. I would love if someone could step forward and say "Hey, Göran? I believe in that and I am willing to take charge of it for the moment - what should I do?". Then we could "just do it". At the moment I am still swamped, and when I do get time I think SM deserves it first anyway.
2. Regarding moving squeak.org. Move it before or after we have a plan of how to improve it? Again, I must say I am with Cees - move it first. Then we have the freedom to improve it. If nothing happens, so what. Btw, my HomepageBuilder stuff has evolved further and has Swiki like capabilities while it still looks like a regular website. We could perhaps use that.
3. Regarding money. I don't think money either solves the issue or is available. :) But we *do* have some money in the PayPal account that Cees set up and we currently use it to pay for the new virtual server. It is at least a start. And we have a server that *we* own. Currently I, Ken Causey and Cees are messing with it. I am just about to add a remote-backup facility and BFAV has AFAIK already moved over to it. SM will move too.
regards, Göran
On Jan 28, 2005, at 1:53 AM, goran.krampe@bluefish.se wrote:
A few short reactions without blabbering:
A few short reactions from me too... :)
- Regarding keeping up with all the work (harvesting primarily). Yes,
Cees is right. Packaging, packaging. This is TFNR all over, and we really need to move forward with that. It is nice to see that more and more people are getting convinced. I would love if someone could step forward and say "Hey, Göran? I believe in that and I am willing to take charge of it for the moment - what should I do?". Then we could "just do it". At the moment I am still swamped, and when I do get time I think SM deserves it first anyway.
Yes, harvesting and the update stream(s) have been somewhat dead in the last couple of months. I have also been swamped with work and haven't been contributing much to Squeak lately, which I feel sort of bad about, but we need to improve our development process so that it doesn't rely too much on any one person. (And I will probably be back doing more Squeaky stuff in a month or so.)
One relatively easy move in that direction would be to simply open the update stream to a larger number of people, say, anyone who has Master status on Squeak People, which would be 19 people. Plus maybe a few hardworking Journeyer people. Also start using the unstable stream consistently, and regularly move batches over to the stable stream, which is easy.
Yes, packaging, packaging. :) I started to write a lost post about packaging a couple of weeks ago, and then realized the issue wasn't as simple as I had thought, while writing it.
Anyway, it sure seems like it shouldn't be impossible to start dividing the base image into its remaining big chunks by using PackageInfo. Don't bother actually removing code from the image yet, just assign all the code to packages via the update stream. (Basically via doits which assign existing code to packages.) Keep the packages very coarse-grained at first, e.g. Morphic, MVC, Graphics, Kernel. (The existing Class Categories are too fine-grained. We'd just have a global list of PackageInfo instances to define the packages, right? Shouldn't any PackageInfo instance be able to "unload" itself, also? Not necessarily successfully, of course. :-) )
Then continually refine which code (especially method extensions) is in which package via the update stream. The package concept would need to be more pervasive in the UI, in browsers, etc. Later on, the packages could be put on SqueakMap. (And then you start to really need some sort of dependency mechanism, but IMHO it's not critical to have while doing the initial splitting.)
I suppose this is probably what the TFNR project was trying to do, more or less. But maybe we could just get it started now with the update stream. Sorry, this is mostly brainstorming, I don't think I will be able to lead the packaging effort itself.
- Regarding moving squeak.org. Move it before or after we have a plan
of how to improve it? Again, I must say I am with Cees - move it first. Then we have the freedom to improve it. If nothing happens, so what. Btw, my HomepageBuilder stuff has evolved further and has Swiki like capabilities while it still looks like a regular website. We could perhaps use that.
Moving squeak.org didn't seem necessary to me at first, but I think you're probably right, that it will be more likely worked on if it is moved. Mostly, it needs a single person to take on the role of lead maintainer of the content. (The download page is in pretty decent shape now, mostly the other pages need work. Most seriously, having an "About" section called "Entering 2000" is really REALLY bad and needs to be removed.)
- Regarding money. I don't think money either solves the issue or is
available. :) But we *do* have some money in the PayPal account that Cees set up and we currently use it to pay for the new virtual server. It is at least a start. And we have a server that *we* own. Currently I, Ken Causey and Cees are messing with it. I am just about to add a remote-backup facility and BFAV has AFAIK already moved over to it. SM will move too.
I agree that a model of paying people probably won't work for actual Squeak development. But money is definitely good for paying for things like the squeakfoundation servers, backup servers, Squeak CDs, and maybe even things like "bounties".
- Doug
On Mon, 31 Jan 2005 01:27:13 -0500, Doug Way dway@mailcan.com wrote:
I started to write a lost post about packaging a couple of weeks ago, and then realized the issue wasn't as simple as I had thought, while writing it.
Only then? ;P
Anyway, it sure seems like it shouldn't be impossible to start dividing the base image into its remaining big chunks by using PackageInfo.
Sounds like a workable plan. But I'm not sure it'll work - it's too gentle, to little pressure to actually get there, so I fear only little work will be allocated to it.
That's one plus point of 'my' plan (Total Breakage[tm]) - it'll force the issue ;).
Hi,
One relatively easy move in that direction would be to simply open the update stream to a larger number of people, say, anyone who has Master status on Squeak People, which would be 19 people. Plus maybe a few hardworking Journeyer people.
Ok, how does one get one's status bumped up ?
Brent
On Tue, 2005-02-01 at 07:15 +0200, Brent Pinkney wrote:
Hi,
One relatively easy move in that direction would be to simply open the update stream to a larger number of people, say, anyone who has Master status on Squeak People, which would be 19 people. Plus maybe a few hardworking Journeyer people.
Ok, how does one get one's status bumped up ?
Brent
My first suggestion would be to put some information on your SqP personal page that helps remind us of the contributions you've made to the community and the experience you have with it. Secondly I don't see any reason you can't lobby individuals for an upgrade. It only takes one Journeyer or higher to mark you as Journeyer for you to become one (at least I think).
Ken
P.S. I've upgraded my certification of you.
On Tue, 01 Feb 2005 10:45:02 -0600, Ken Causey ken@kencausey.com wrote:
It only takes one Journeyer or higher to mark you as Journeyer for you to become one (at least I think).
Not necessarily. There is some complex mathematics involved (well, complex to a dork like me who is almost 20 years past his formal math training ;)). Basically a bucket of points is poured into the network by the roots, and it flows according to certification level. There are also sinks, and the whole shebang results in the cert list.
It could be that it currently works that way, but it is certainly not a rule appearing somewhere in the flow algorithm.
On 28 janv. 05, at 3:06, Lex Spoon wrote:
This talk of paying worries me. I see many open source projects that do very well with very little funding. I see many people participating in Squeak -- after all, just look how many ENH's we have. :) Surely there is a way to channel all this energy, especially given the large number of successful OS projects in the universe?
But who is collecting and taking care that the enh are getting in the image? Who?
I fear that if we use money to prop up our current situation, we will just keep on doing things in a sub-optimal way. Surely we can figure out what the other guys do, that we do not? I do not oppose spending money in general on Squeak; I simply worry about trying to use it to speed up business as usual.
Here here!! You are all tired of hearing it, but Debian does *fabulously* on very little money. 8000+ packages and 900+ developers. A major part of Debian, I think, is that everything is divided into packages and each package has a maintainer. Un-maintained packages are gradually marginalized and then removed from the distribution. When there is a bug report, it's easy to see who is responsible, and it's easy for the responsible person to become aware of it.
Are there any bugs posted against Chuck right now on Mantis? I have no idea. And what about Nebraska, which is still in the image? Eek. In Debian, I have exactly two bug reports open.
yes but packages does not work really now. So this is the future clearly but now. I'm talking about looking at the fixes and enh and creating new images.
Stef
Hi. I'm upgrading some stuff from 3.5 to 3.7 and I found some modification in Date implementation. I had done some modifications in Date class to avoid ambiguities such as
(Date newDay:1 month:12 year:1) = (Date newDay:1 month:12 year: 2001) true
and I'm happy to find that now this is fixed. Now historical dates exists. But I notice that
(Date year:1 month:12 day:1) julianDayNumber 1721760 (Date year:0 month:12 day:1) julianDayNumber 1721395 (Date year:-1 month:12 day:1) julianDayNumber 1721029
That's wrong, since year 0 doesnt' exists. The second line is returning the julianDayNumber of year -1 (A.C) and the the third, the day of year -2. I have adapted my class that supported non ambigous dates (and other features) to correct this, overriding the creation method to sum 1 one year, but I think it must be corrected in Date class itself. I tried, but I found it hard, at a first glance. Don't you think this may be fixed?
Cheers Norberto
Hi,
The ANSI compatible DateAndTime and Duration classes were introduced in 3.7.
I am the developer and maintainer of that portion of the image.
If you can reply to me next week, preferably with a DateTest unit test illustrating the desired behaviour I will eagerly look into it and motivate for any fixes to be imcluded in the 3.9 image.
Brent
Hi, Brent -
The ANSI compatible DateAndTime and Duration classes were introduced in 3.7.
I am the developer and maintainer of that portion of the image.
If you can reply to me next week, preferably with a DateTest unit test illustrating the desired behaviour I will eagerly look into it and motivate for any fixes to be imcluded in the 3.9 image.
While you are at it, I just ported my weather station app forward from 3.6 tp 3.8 and found that all display and scrolling was suddenly 4x slower. I tracked this down to a couple of Date and Time operations that are slow in 3.8, such as addDays, and dayOfYear. By restoring my former logic, I sped these up (dayOfYear by a factor of 50!), and everything went back to behaving normally.
Below is my code for dayOfYear in case you find it useful. I can also send you a simple method for <Date>daylightSavingsInEffectAtStandardHour: which can be very useful.
- Dan
-------------------------- dayOfYear
| monthStart | true ifTrue: ["This code is 50x faster..." ^ self dayMonthYearDo: [:d :m :y | monthStart _ #(1 32 60 91 121 152 182 213 244 274 305 335) at: m. (m > 2 and: [Year isLeapYear: y]) ifTrue: [monthStart + d] ifFalse: [monthStart + d - 1]]] ifFalse: ["Here is the ANSI code..." ^ jdn - (Year year: self year) start julianDayNumber + 1]
Hi,
From the preamble:
This enhancement was contributed by Dan Ingalls, I have just packaged it up as an enhancement and confirmed it passes all exising tests.
It replaces the implementation of DateAndTime>>dayOfYear to speed it up by a factor of 80.
All 394 test cases in the Kernel-Chronology Tests category succeed in a 3.9a-6531 image.
now := DateAndTime now. [ 10000 timesRepeat: [ now dayOfYear] ] timeToRun
Results: 2694 milliseconds with old code, 33 milliseconds with new code.
It should be imcluded in 3.9 soonest.
Thanks
Brent
It should be soon included into the main stream
Hi Dan,
Thanks for your enhancement to dayOfYear. I have submitted it as an enhancement.
I can also send you a simple method for Date>>daylightSavingsInEffectAtStandardHour: which can be very useful.
Please send me this method.
#daylightSavingsInEffectAtStandardHour: has been deprecated but this can obviously be undone if it is a used method :).
I must confess that I live in a country with one time zone and no daylight saving, so my experience of what support is required is theoretical. Any siggestion on a test case for the daylight saving methods in Date would be really helpful.
Brent
On Sat, Jan 29, 2005 at 10:45:15AM +0200, Brent Pinkney wrote:
I must confess that I live in a country with one time zone and no daylight saving, so my experience of what support is required is theoretical. Any siggestion on a test case for the daylight saving methods in Date would be really helpful.
Hi Brent,
You might be interested in looking at TimeZoneDatabase on Squeak Map. This includes a TimeTransformTest test case with lots of tests that exercise time zone transformations (time zone offsets, daylight savings transitions, and leap seconds).
The last release I made for this is an attempt to wire it in to your Chronology framework. I'm not entirely happy with the way I did this, because it touches too many Chronology methods, but it's at least workable and it's fun to poke around with it. Having it in Squeak makes it possible to use an object explorer to poke through the database and figure out how the rules work.
I'm not aware of anybody actually using TimeZoneDatabase so this is not something I'm planning to put much additional work into, but I would certainly appreciate any feedback you might have. (Actually I'm not sure why I ever did this package in the first place, it just seemed like an interesting thing to figure out ;)
Dave
squeak-dev@lists.squeakfoundation.org
-
bergel＠iam.unibe.ch -
Brent Pinkney -
Cees de Groot -
Dan Ingalls -
David T. Lewis -
Doug Way -
goran.krampe＠bluefish.se -
Ken Causey -
Lex Spoon -
Norberto Manzanos -
stéphane ducasse