[squeak-dev] Re: Community Supported Packages

Andreas Raab andreas.raab at gmx.de
Mon May 17 05:56:19 UTC 2010


Hi Sean -

Correct me if I'm wrong but what you're saying sounds as if we're in 
violent agreement :-) Yes, having a more specific version info for 
Metacello is needed and a Good Thing (tm), no doubt about it. OTOH, the 
specific version info doesn't solve all the problems when dealing with 
the issue of package and image versions (as you're admitting below). So 
it seems we're in complete agreement here.

Cheers,
   - Andreas

On 5/16/2010 6:31 PM, Sean P. DeNigris wrote:
> Teleplacer wrote:
>>
>> The point is that if there's a sufficient number of users in our community
>> who say
>> "this is important for us, we want it to work" they should be able to
>> support that software as part of a community effort regardless of
>> whether the original project developers 'officially' support it or not.
>>
>
> I agree completely.  And, this will only apply to some projects.  Maybe have
> both - default to pointing to the community version unless there is a reason
> to physically copy and take control of it.  From the image perspective, the
> user wouldn't have to know if they were loading a Squeak-controlled Config
> or a central one.
>
>
> Teleplacer wrote:
>>
>> version designators... doesn't
>> address my concerns about the cross-product of package and system
>> versions. Quite the opposite: My concern is more that when you have five
>> potentially supported image versions there is a high probability that
>> just for simplicity people will only support certain combinations.
>>
>
> * How versioning helps: For simple cases, just adding versioning to the
> current central repo, a specific fork/version could just add a for:
> fork/version do: [] to the shared Config and a Xxx-Platform package.
> * A project inbox could be cool: I really liked you inbox idea for non-core
> projects, but I would like to have a cross-fork project inbox where the
> community could contribute.  For example, when I ported ExternalWebBrowser,
> I didn't have write access to SqS, and the port was to have it work on Pharo
> on Macs, so I had to break it into Core and Platform packages.  But now, I
> had a Platform.pharo and Platform.squeak, so I really needed a project inbox
> without the artificial division of forks.  I ended up creating my own SqS
> repo, and not knowing if I should upload the Config to the central repo
> because it only worked with my unapproved altered project, which confused
> people.  A project inbox would allow people to easily find and choose my
> version or the project owner's...
> * Metacello spec could be a limited guarantee - The other thing that I
> forgot in my other post, is what if there was an option in Metacello to
> install the closest? or any? version if the current fork/version combo is
> not available (kind of like Squeak Map's loader)?  So the fork/version
> Metacello spec would be a guarantee to work, and not a restriction where the
> Config will only do anything if the current platform is listed.  Now the
> automated testing/compatibility server iterates through the Configs, and
> either:
>      - files an issue, or somehow announces that this fork/version can be
> safely added to the Config
>      - if the project meets the standard, adds the Config to that list
>      - if it doesn't meet the standard, adds the Config to the unsupported
> list, with a category of the result e.g. "installs but fails tests," "does
> not load," etc.
>
>
> Teleplacer wrote:
>>
>> To give a concrete example, just yesterday there was a discussion on the
>> Seaside list about Seaside 2.8 on Pharo 1.1. Apparently, it's no longer
>> supported, and that's a fine choice for the Seaside developers. But it's
>> not quite as clear-cut if it's an equally fine choice for the Pharo (or
>> Squeak) users of Seaside 2.8. And here's the issue: If you assume that
>> the Seaside configuration comes from the Seaside folks (stored as
>> ConfigurationOfSeaside in the external repository) then you're
>> completely buying into that particular set of supported configurations.
>>
>
> This would be one instance where copying and taking control of the project
> would be the way to go.  I just think it adds unnecessary complication to
> have this be the default.
>
>
> Cheers,
> Sean




More information about the Squeak-dev mailing list