No, we don't "all agree". That's my point. If you consider the above to be serious flaws that need to be fixed then please explain to me what the "desired code quality" is that you are trying to achieve. To me, this is nit-picking.
You don't, but Yoshiki agrees. I have no ideas what issues he is working on, and what their intersection is with the ones I raised but he's stated that we shouldn't integrate the current version.
I don't consider the above to be "serious flaws". I consider the above to be the kind of small cruft that naturally accumulates when building something, and gets easily cleaned out *before* it gets integrated and forgotten, so that we don't one day need a TTFCP. You think this is nit picking, I think code should be clean as it can reasonably be. The price to clean it today is tiny compared to the price paid by everyone that will try to maintain the code in the future.
If alpha is closed without the TTF stuff it means you've delayed the most important improvement to Squeak's user interface in the last three years.
Have you ever failed a test because you didn't put in the effort and had to do it over? did you blame the teacher for writing the test?
You may see things so that you think that I'm delaying this code, but this code could easily be cleaner, and you know it, and you can do something about it just as easily as me. As for my role in this, I don't agree that welcoming cruft into Squeak arbitrarily is the way to advance it.
I think this is clearly about values, and maybe about that "Vision" you were looking for so hard - I think Squeak's code should be something that people enjoy reading. I think much of the power Smalltalk has had over Smalltalkers' ideas comes from teaching them by example "this is how it should be". Cruft in the Basic Squeak image sabotages that effect, and makes Squeak weaker in something that really matters. I'm going over to a friend whom I'm teaching Smalltalk, we'll be looking at squeak code, and he'll be asking "why did they do that?" with all intention to learn something new. And I'll say to him, "Oh, no, ignore that, some people think it's ok to let cruft into the image (but look at the beautiful fonts it gives us!). Here, look at this bit, this one is good... well mostly".
[Conflicts are hard to find] Well, yes. Do you think that the fact that conflict detection is hard means that we should ignore it? We can do the work at integration, or we can be surprised later by problems in releases newbies use. This extra work is the price of distributed development. The problems of unchecked conflicts will get worse with more contributors. BTW, feel free to try out and improve Dougs conflict checker.
[DecPools and KCP] The fact that conflicts with packages are hard to solve is a sad consequence of not having package releases. It is made more difficult by having more packages, but the solution is not in going back to a monolithic image, but in improving our infrastructure (SM1.1). Wish I could give you a release date for that, but I can't. When we're talking about a package, like RB, what I did was fork it into two packages. When we're talking about a patch like DecPools, I would track the current alpha, because the version for an old 3.6 won't be particularly useful to anyone.
Daniel
Andreas Raab andreas.raab@gmx.de wrote:
Hi Daniel,
Do we disagree on the code, on the software engineering rule of thumb, on its application to this code, or on its application to Squeak code in general?
We disagree on the terms "flaw" and "error". The issues you originally mention may (depending on ones interpretation, certainly not mine - see below) be seen as "flaws" but there are definitely no "errors" in what you describe. None of them (not a single one) will prevent Squeak to function correctly.
I don't see what this has to do with beta
It has a whole lot to do with beta. If alpha is closed without the TTF stuff it means you've delayed the most important improvement to Squeak's user interface in the last three years. For reasons which I find impossible to follow.
I also never required that conflicts be checked with "all ongoing work" - MCP is part of Squeak 3.6 as of 5240, IIRC. Conflicts with previously included work should be detected and resolved, of course - when we don't do this, we get the annoying "didnt I fix this already" effect.
Are you aware that right now this is almost impossible? For example, I've posted the declarative pools at SqueakMap and there are a few conflicts with KCP changes. Fixing these conflicts means that suddenly noone in pre-3.6 systems can load this any longer. So how do you propose to proceed in this situation?
I'd argue that what we want to do is to load the existing code base and fix the conflicts as things get integrated. This leaves the package at SqueakMap alone and will allow others to use it, too.
[snip]
On the other hand, the work hasn't been done yet to bring it up to the desired quality level.
Desired by whom? Looking at your critique in detail:
- at least one method clashes with MCP.
It's not "at least" one method but "exactly" one method and the conflict is that some "verb first" has been reverted to "verb at: 1".
- The single GrafPort method sends to super but
implicitly returns self.
I don't get the point here. Why can't a method send to super and implicitly return self? In any case, it seems that this method is just a left-over from later improvements.
- Paragraph>>asForm does an "isKindOf: TTCFont"
Again, what's your point here? Paragraphs have to know fonts or else they can't function correctly. One can argue that using isKindOf: is generally not good style (and I agree on this) but in this particular case the action taken is so specific for TTCFonts that it makes perfect sense to use #isKindOf:.
Claim I - We have a piece of code that's candidate for inclusion. We all agree it has flaws as detected by even cursory inspections.
No, we don't "all agree". That's my point. If you consider the above to be serious flaws that need to be fixed then please explain to me what the "desired code quality" is that you are trying to achieve. To me, this is nit-picking.
Cheers,
- Andreas
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi Daniel,
If alpha is closed without the TTF stuff it means you've delayed the most important improvement to Squeak's user interface in the last three years.
Have you ever failed a test because you didn't put in the effort and had to do it over? did you blame the teacher for writing the test?
Yes, but in these situations the rules were clear to me and I knew what exactly I should have done differently.
Again: Please explain to me what your desired code quality is. What measures do you use? What are the rules?
You may see things so that you think that I'm delaying this code, but this code could easily be cleaner, and you know it, and you can do something about it just as easily as me.
Only if I know the rules. Otherwise I can only wait until there is some critique here or there and depending on your workload this may take days, weeks, or months.
[Conflicts are hard to find] Well, yes. Do you think that the fact that conflict detection is hard means that we should ignore it?
You lost me here. Finding potential conflicts with other packages is quite simple once you've got the stuff loaded. Just go into a dual change sorter and choose "conflicts with other change sets" and it'll list you all of them. Then you turn on the diffs and voila! all your conflicts get nicely highlighted. Fixing them can be a different matter though ;-)
[DecPools and KCP] The fact that conflicts with packages are hard to solve is a sad consequence of not having package releases. It is made more difficult by having more packages, but the solution is not in going back to a monolithic image, but in improving our infrastructure (SM1.1).
You lost me again. I don't see how the above is related to my question about how to handle a concrete case in a concrete situation. Please explain.
Wish I could give you a release date for that, but I can't.
I sure hope it's soon. I already started to manually mirror important packages in order to be able to rely on the right versions. It sucks like hell but there's nothing else I can do.
When we're talking about a package, like RB, what I did was fork it into two packages. When we're talking about a patch like DecPools, I would
track
the current alpha, because the version for an old 3.6 won't be
particularly
useful to anyone.
I think it's quite valuable to have it available for older Squeak versions. The point is that someone may want to load a package which contains a declarative pool in something like 3.4/3.5. Having the package at SqueakMap means that they have at least a chance to try it.
Cheers, - Andreas
squeakfoundation@lists.squeakfoundation.org