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
-- 
View this message in context: http://forum.world.st/Community-Supported-Packages-tp2217473p2219002.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.