[Squeakfoundation]re: TrueType font support and 3.6

[Daniel Vainsencher]

I'll take that as a reminder that we haven't yet created the official
submission/review policy we talked about last week. Here's a draft -

Code submitted should be the simplest thing that could possibly work
(*), where "work" is defined as providing the functionality promised
(ENH) or correcting the bug (FIX) without creating others.

(*) note that this precludes, among other forms of complexity -
1. Dead code that does nothing.
2. Extensions to existing classes that are not strictly required for the
code to work.
3. Breaking or undoing other peoples changes.

Andreas, does this help?

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> 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 mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation