[squeak-dev] [Packages] Packages Team and List rejuvenated!

Dear All,

now that we have Installer, LPF, SqueakMap, Universes, DS, MC2, and
Sake/Packages we have never had so many different solutions for
packaging and loading our stuff.

The packages list has been dormant for a long time now, so I am aiming
to give it a fresh start.

We shall begin by supporting the http://www.squeaksource.com/Packages 
repository, and see how we get on. Commits will be automatically posted
to the list from squeaksource (thanks matthew).

Informal bug reports on any of the above items will also be welcome,
though of course mantis is the preferred place for formal bug reporting.

So.... What exactly are we aiming to achieve?

GOALS
======

The first goal is to use Sake/Packages to create a definitive model of
all squeak packages, which versions load into which images in what
order, for both stable and unstable releases.

So far we have separate packages with definitions for:

PackagesSqueak310
PackagesSqueak39
PackagesSqueak38
PackagesSqueak37
PackagesSqueakMap (auto generated from SqueakMap itself)

Other projects, croquet, sophie, etoys, and pharo are most welcome to
have their own package in this repo, or elsewhere if preferred.

General unstable/latest package definitions are placed higher in the
class heirarchy, with more specific "this definitely works" definitions
in leafier subclasses.

To install sake/packges

Installer install: 'Packages'.

or

Installer install: 'PackagesAllVersions'.

Do subscribe to the [hidden email] to give feedback
on what does and does not work correctly. If you are a Universes user
and have noticed any problems with Universes, then we can absorb that
knowledge into the model, and poke universes maintainers to pick up the
new data.

many thanks in advance

Keith

p.s. if you are on the pacakges list and this new flurry of activity
makes you nervous please feel free to complain.
p.p.s. emails sent to the list by non-subscribers should get through
eventually, if you just want to report a problem but not discuss it further.

I'm asking again....then.....if I'm a user of SqueakMap, all will continue working?

If I'm a user of Universes, all will continue working?

If I don't have plans to use Sake/Install/etc.....can deatch of them?

If I'm a Squeaker with not much time to be aware of all the news all the time, because must work on projects to pay the bills, I've option of ignoring this several ways of installations and packages?

If I develop my own software in the form of traditional Monticello .mcz packages, I can continue at this way?

Sorry if a lot of questions, but I'm a bit confused with all these new things related to packages.

Cheers.

Germán Arduino wrote:
> I'm asking again....then.....if I'm a user of SqueakMap, all will
> continue working?
Definitely.
> If I'm a user of Universes, all will continue working?
Yes
> If I don't have plans to use Sake/Install/etc.....can deatch of them?
Installer is designed to be the first dependency in a kernel image that
can be used to load everything else. So I would like to promote it's
inclusion in as many base images as possible. However it is purposefully
implemented as ONE class in order to make it very easy to remove.

Sake/Packages is also designed to be very easy to remove if it is
loaded. It is deigned to be able to load , use AND discard if you like
your images really lean.
> If I'm a Squeaker with not much time to be aware of all the news all
> the time, because must work on projects to pay the bills, I've option
> of ignoring this several ways of installations and packages?
of course, ignore away!
> If I develop my own software in the form of traditional Monticello
> .mcz packages, I can continue at this way?
Sake/Packages, SqueakMap, Installer and Universes all use Monticello so
yes you keep using Monticello as normal.

The easiest way to understand Sake/Packages is to think of it as the
same as Universes for loading and unloading Monticello packages that
have dependencies upon other packages. I believe that Sake/Packages is
better than Universes in many ways, but then I am totally biased since I
wrote it.

The significant difference between sake/packages and universes is that
the former is open to all, whereas universes can be updated only by
package maintainers. This means that sake/packages is likely to be more
agile, and up to date.

Currently there is an automatic task which updates Sake/Packages from
Universes and from SqueakMap. There is nothing preventing someone from
writing a task to go the other way in order to keep everything in sync.
(except of course Universes would have to be globally writable by the
person performing the update).

> Sorry if a lot of questions, but I'm a bit confused with all these new
> things related to packages.
>
no worries

Keith
 

Thanks by the responses.

On Fri, May 16, 2008 at 2:14 AM, Keith Hodges <[hidden email]> wrote:
>
>  I believe that Sake/Packages is better
> than Universes in many ways, but then I am totally biased since I wrote it.
>
> The significant difference between sake/packages and universes is that the
> former is open to all, whereas universes can be updated only by package
> maintainers. This means that sake/packages is likely to be more agile, and
> up to date.

I wouldn't call this "better", I would call it different.  Universes,
as far as I understand, are about stability.  I.e. someone has to
"sign off" that packages work together before they get included.
Debian works this way and it lets you do things like allow updates to
just get applied to your server automatically because you can have a
pretty high confidence that no updates will happen if there is a doubt
about how they react.

You stuff would be preferred in a setting where the user is more
"hands on" and always wants the latest even if it causes a crash now
and then (stated another way:  production vs. development).

Jason Johnson wrote: I was stating my belief based upon spending almost a week attempting to
use Universes to put together a complex image for production, it really
doesn't live up to those expectations.

The question here is whether stability can best be acheived through a
signoff process, or by allowing a multitude of testers to feedback their
results as quickly as possible.

In the case of debian, there is no way you can expect an average user to
feedback changes, running test suites etc. Each package is too
specialist. Squeak on the other hand is much simpler and many people
have the wherewithall to do so.
>  I.e. someone has to
> "sign off" that packages work together before they get included
 ...snipped...
> You stuff would be preferred in a setting where the user is more
> "hands on" and always wants the latest even if it causes a crash now
> and then (stated another way:  production vs. development).
>  
Not at all. I began with a requirement to build a production image, and
Universes doesnt allow you to do that. If one piece is out of place you
have to abandon universes and do it manually.

Either way you could argue that the majority of squeak users are in
development at some level anyway.

best regards

Keith