Hi lex
We are all volunteers and we do a lot during our nights. And I'm sorry but if one person would help doug the process would go faster. At one point in time I was the only harvester and I can tell you that when marcus joined it was a great feeling.
Lex my main point is that if somebody payed to code in Squeak would spend 1 hour every three days then this would make a big boost.
So I disagree with you, steven cannot say we need shorter iteration cycles, stabler versions and not participate. There are certainly some problems with the current process but it starts to work. Now we have to improve it this is clear, but without BFAV we would be nowhere right now. (Thanks for all the people that are working to improve it. This is really important). I remember the SqueakC time where not funny, cool compiler fixes where simply lost (certainly because of time problems too).
I think that for example a Guide for eToy and Multimedia is NEEDED. I was discussing this issue off-line with the other guides. Now if you find a guru in each the part of Squeak then this is clear that the current process is not efficient enough still having another person browsing your code is always good. At least for me I really appreciate that someone have a look at my fixes because sometimes I'm idiot, tired, or thinking to something else.
Stef
u wrote:
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:
On 27 juil. 04, at 10:14, Marcus Denker wrote:
If you depend on squeak, you should try to get involved with the harvesting process (or work on improving/replacing that process). You can view that as an "investment" in your own future.
I totally agree with marcus. It is CRUCIAL that people making (or wishing) to make money with Squeak invest also in the process. Note that for me I could live happy with any image I patch and do not care to give the result back to the community. In general this costs me to send/harvest changes and I do not get money (nor wish to make money with squeak).
I disagree. The current harvesting process is quite inefficient, and we need to fix it, not get even more people to work on it. It is not a good use of time to go through endless patches, most of which any individual reviewer cannot add input to.
To put it another we, we already have TONS of volunteer effort in Squeak. It is crazy to suggest that we need even more before we can make progress. Somehow, we need to figure out how to rationally use the tons of effort we already have.
To show what I am talking about, let me give you a quick story. I received an email a couple of days ago asking that I resubmit a FIX and this time include a test case. Actually, the post did include a test case; it simply wasn't in SUnit form. When I tried to write one, I noticed that the code was no longer broken! It turns out that someone else had fixed it, this time with a SUnit test, and had their fix included.
What do we see from this example?
- Email was wasted because a clear fix is not done in the most
perfect beaureacratic way. All someone had to do was run the example one-liner that was broken, look at the patch, try the patch, run the code again and see that it was fixed.
Multiple people have fixed the same bug. This is wasteful.
Everyone is having trouble searching BFAV. At least two people did
not realize the same bug had already been fixed: the person who emailed me, and the other person who fixed it. I myself wasted time trying to build a SUnit test case for something that had already been fixed without my noticing. 4. On the whole, much more effort was expended talking about this bug and the different fixes, than was spent solving the problem itself. This patch changes two lines of code, for a grand total of 14 characters. (It changes "Number" to "Integer" in two places.) Even going through an expedited cross examination would have been overkill for such a tiny patch, but when you look at the quite slow process that happened in practice, it is truly awesome how inefficient we were at dealing with this bug.
My favorite direction to go in would be to put reasonable people in charge of various parts of Squeak, as we have already begun to do so. And if some part of Squeak is too obscure for anyone to volunteer as the maintainer of it, we shouldn't lose too much sleep that it is not being maintained. Once maintainers are in place, we can trust those guys to do the right thing most of the time and not subject them to lots of cross examination on every little change.
If there is a problem with getting people to volunteer, then perhaps the first person to post a fix to a new area should get a chance to become the maintainer for that part. After all, they new enough to fix something, so they have to be a reasonable choice.
Anyway, to make this approach work really well, BFAV would need to have tags for which part of the system a bug report is associated with, and it should be possible for people to reassign those tags. Alternatively, of course, we could use any existing off-the-shelf bug tracker; all of the ones I've seen have this functionality. Even email might work better, honestly, if we also had a swiki page listing the points of contact for each portion of the system.
At any rate, let's please back off from trying to recruit more people to get out of the car and push. Let's focus on getting the engine started.
Lex