Stéphane Ducasse wrote:
Hi guys
we have a roadmap for Esteban and we would like to share it with you. We have extra items that we would like to see fixed and we are welcoming your
feedback/suggestions. Note this is typically the way we want to work with the consortium in the future:
Build an initial roadmap and refine it based on the input of the
community.
- A website for the consortium registration (esteban is expert on that).
- This is important for INRIA and for the visibility of the consortium. We should get new members :)
- Integration with SmalltalkHub
- Working on fixing bugs!
- Debugger fixes
- Continuous bug fixing.
- Improving release process: faster, more people involved, simpler.
- Working on metacello repositories for each distributions (everything
is there but missing last bits)
- Metacello tools
- Automatic release validations
- Automatic validation of fixes
Now the free items with probably igor involvement
- Multiwindowing support
- Fully working multithreaded FFI with ***Documentation***
- Filesystem fix and integration
- Integration of OPAL
- RPackage integration
Igor related
- Ephemerons
- Object format
- VM branding
- Use of new canvas
- Event cleaning
So we are waiting for your suggestions.
Stef
Just a very general view... that in paid positions, you don't always get
to work on the sexy stuff. One of the downsides of open-source is the
chance that developers might focus on the fun 80% of their ideas before
moving on to the next-big-thing(c). It is easy to develop something to
be used by oneself. It is much harder to develop something to be used
by others - particularly in providing a sense of how to use the system
by way of well documented examples. There is a lot of drudge work to
make a system successful and stable. Knowing there is a paid position
that might deal with part of that work definitely increases confidence
in the system.
One new idea. I really like the way Wordpress manages their thousands
of Plugins with the "Compatability" sidebox where you choose a Wordpress
version and a Plugin version and it indicates how compatible they are
based on user votes. However rather than (or as well as) user voting I
think that TestRunner results from applications could be used - and also
presented in a tabulated form rather than just pull-down choices showing
a single sample point. A continuous integration and testing system
would take combinatorial approach to testing registered Metacello
configurations - which might take a lot of processing power and leads to...
A second idea for a distributed continuous integration test system. I
would personally be happy to contribute cpu cycles to running a Pharo
test system on top of a virtual machine, which from a central server
obtains a random set of Metacello configurations to install, runs tests
and reports results to the central server. Apart from gaining the
processing power to possibly test all permutations of configurations, it
also provides a way for new community members to feel like they are
contributing, which preceeds them getting more involved. As an example
in line with my first comment, perhaps the initial proof of concept
would be done as a research project, and then the paid professional
would polish off the stability and usability of it.
cheers, Ben
