[squeak-dev] [Cuis] Cuis - Cross fork compatibility of packages:
A proposal
keith
keith_hodges at yahoo.co.uk
Tue Jan 26 02:06:14 UTC 2010
> Hi Folks,
>
> (reposted, in the hope of not being ignored)
>
> Package developers want their work to run on various Squeak versions
> and variants, without needing rewrite. Same for app developers.
>
> Base image builders want to be free of the need to provide backwards
> compatibility.
>
> This is what I suggest: A package assumes it can use a set of apis
> of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment.
> Those assumptions should be made explicit, in the form of tests. So,
> for example, for collections, some package developer might require
> the "Common Collection API tests" to pass. Then, if his package
> fails to run, let's say in Cuis, he would run the tests for the apis
> he needs. If some test fails, he could say "Cuis developers, you're
> not supporting api XXX", end expect them to fix the issue. But if no
> test fails, he needs to either modify his code so it doesn't use not-
> standarized apis, or he could negotiate with (all) base image
> developers the addition of a new api or use case to the test suite
> and the base images.
Agreed wholeheartedly.
For this vision to have a chance, absolutely one thing is 100%
essential. SUnit must be common, between forks, and there must be some
way of flagging known exceptions for different target images. This is
something I attempted to add to SUnit in August 2006, in eagre
anticipation.
The second essential thing is for the package loading tools to also be
in common. That means Monticello (in my book, though probably not in
yours).
However, most forks imho are keeping all of their libraries too close
to their chests.
All efforts to change this, to move obvious loadable libraries like
SUnit, and MC out to be externally managed, have up to now failed. The
weakness of my attempts so far has been in the testing side of things.
(Matthew Fulmer is worth is weight in gold on that one)
However Monticello is a complicated beast, I may have made 400 more
commits, merging 3 forks, but one or two bugs is all it takes to
reject the entire refactoring of the repositories code, the improved
more uniform ui implementation, the password manager, the dual change
sorter, the orphanage for out of order loading, public package info
properties for package managers, scripting of commits, memory analysis
per package, the atomic loader, cleanUp code, improved version
numbering, integrated Configurations, separated tests, default
packageinfo package types etc etc etc.
I always needed others who are more rigourous to join in and help, but
so far the vision hasn't caught.
I now think it is going to fall to the forks for whom the libraries
are already genuinely optional, to pioneer this process. i.e. Cuis.
> Building these suites is quite some work, mostly to be done by
> package developers.
As I said, if you try to treat what is perceived as an integral
library as an external package, to be maintained by a package
developer, with the API maintained by "actual conversation" between
the fork-leaders and the package maintainers. The fork controllers
wont have any of it, they forked for the purposes of retaining
control, and wild horses wont shift them.
I tried, I asked, I begged, I cried, I explained, and I ranted, in the
belief that it was now or never. Up until Pharo, all "forks" were
basically differing applications on the same evolving kernel. With
Pharo this is different, they are moving the Kernel in a different
direction on purpose, however for some reason they believe that
forking SUnit, an obviously loadable package, is necessary too!
Correct me if I am wrong, but in my thinking if SUnit is forked, your
vision is pretty doomed.
SUnit is forked.
> But it can easily point out responsibilities and duties. It frees
> package developers of needing to have a deep knowledge of various
> base images. And it frees base image developers from needing to know
> details about an unbounded set of external packages. Besides, it
> puts popular packages that everybody wants to support on equal
> footing with less-known packages. It also lets base image developers
> say "we support Common APIs xxx, yyy, zzz, etc.".
>
> All what I say about base images could also apply to packages that
> offer services to other packages: There could also be test suites to
> specify their services, and allow users to switch versions of the
> packages they use knowing what to expect.
>
> What do you think?
Like I say, I agree completely, however this is "planning", this is
"thinking", this is showing "leadership", and defining a conceptual
"process", with conceptual roles and responsibilities.
However, may I point out we don't need to do that here, we have a
shared repository you can commit your changes to, its called "trunk".
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100126/584d6b1b/attachment.htm
More information about the Squeak-dev
mailing list
|