Hi Jörg,

> Does anybody knows if we can have prerequisites for packages? The current Monticello configuration stuff with all the multi-repository links and configurations is simply the hell, nothing is working, nothing is loadable.

While Monticello does allow adding prerequisite packages to a package,
this information does not tell it where to get the dependency package
from.

The current solution to that problem is Metacello. Or you can write a
more involved installation script that takes care of the transitive
dependencies for your project and put that on SqueakMap...

> I think the Squeak community needs one central repository where each thing in it is well tested and under control without any side-dependencies to other uncontrollable repositories. I recommend to install a contribution policy where „supported“ things that are added under the control of Core Squeak should have at least a reasonable set of SUnit test cases, so that we can automate the task of testing and building a new Squeak release. Nobody wants to test all things manually :-)
>

For the core Squeak itself, that repository is the Trunk repository.
Not all things are tested automatically and sometimes things do break,
but that is the price you pay for working with the bleeding edge
version of a platform. You could also work with a released version of
Squeak, all of which remain quite stable.

Many things are tested automatically in the Trunk. Automating 100%,
especially GUI tests etc. is not practical with a community this
small. A rigorous policy to reject every contribution unless it has an
automated test would have the progress grind to a halt.

This is not a company that sells a product for a high price with
definite compatibility and quality promises, providing compensation if
things go wrong. This community does its best to not break anything,
nevertheless. Not unlike many open source libraries in the Java and
JavaScript ecosystems, used by corporations around the world to
support their business, but not bound (except maybe by their kindness,
conscience, own values, pride) to suit these corporations or their
policies all the time.

If what you really want is a software repository, like different Linux
distributions provide them, or for example VA Smalltalk provides
(https://vastgoodies.com/), then the nearest equivalent is SqueakMap.
It is not moderated however, and the project owners have to decide
themselves whether they are compatible with a certain Squeak version
or not. The https://github.com/squeak-smalltalk/ organization holds
some semi-endorsed projects (e. g. the FileSystem API port and the
Tonel port) and official Squeak-related projects like the website,
*if* their maintainers decided that they would rather like to work
with Git/GitHub. To put up all third-party Squeak projects there as
they walk by would not provide real benefit over SqueakMap.

Kind regards,
Jakob

Am Sa., 19. Feb. 2022 um 10:54 Uhr schrieb Jörg Belger <unique75 at web.de>:
>
> Hi Bernhard,
>
> That is cool, thanks for the hint.
>
> Does anybody knows if there is something like „email notification“ in Github ?? I mean something where everybody can add itself to an issue or a group of issues or issues with specific attributes/labels. I think when we would have groups like „UI“, „Database“, „Web“ etc. we could group the issues and possibly people can subscribe as example only for „UI“ and get only then emails for things which are interesting for them.
>
> Currently it seems the Squeak Github has no labels or projects, if I click one „New issue“ I cannot select a label on right side or a project. Maybe the Squeak board members can think about several sub-areas like „UI“ and so on.
>
> I think the squeak mailing list should be then used only for really really urgent things, so that not the whole discussion of „other“ projects must be read by all people.
>
> If somebody thinks know to use Github as source code repository, I like the idea only a little bit, Pharo uses it. It has the advantage that nobody needs to run an own server at home :-)
> But the big disadvantage is, that you cannot think anymore in packages with its own version history like in Monticello. You need to think in repositories and branches and if you change two packages that are linked to one Github repository and you commit the first package, then I think you commit the second package too under the same version, because in reality you do not commit the package, you commit your current repository from disk to server. You lost the possibility to version each package differently.  That makes it impossible to load later packageA with version 1.5, but loading packageB with version 2.7.
>
> Does anybody knows if we can have a Github repository where we can think like a Smalltalker and commit single packages ?
> Does anybody knows if we can have prerequisites for packages? The current Monticello configuration stuff with all the multi-repository links and configurations is simply the hell, nothing is working, nothing is loadable. I think the Squeak community needs one central repository where each thing in it is well tested and under control without any side-dependencies to other uncontrollable repositories. I recommend to install a contribution policy where „supported“ things that are added under the control of Core Squeak should have at least a reasonable set of SUnit test cases, so that we can automate the task of testing and building a new Squeak release. Nobody wants to test all things manually :-)
>
> Jörg
>
>
> > Am 19.02.2022 um 10:10 schrieb Bernhard Pieber <bernhard at pieber.com>:
> >
> > Hi Jörg,
> >
> > Actually there already is such a GitHub repository:
> > https://github.com/squeak-smalltalk/squeak-object-memory
> >
> > It is quite new. I just stumbled over it myself.
> >
> > I agree that using the GitHub issue tracker will be an improvement over Mantis.
> >
> > Cheers,
> > Bernhard
> >
> >> Am 18.02.2022 um 20:52 schrieb Jörg Belger <unique75 at web.de>:
> >>
> >> I do not mean to pay now many people, I know it is just a free community. But I think also that community can interact more professional. I got now the hint the opensmalltalk-vm has a GitHub repository with an issue tracker. I think the Core Squeak developers could simply create a giithub account and the issue tracker is for free. It is a better communicating and the free workers can look from time to time into this issue tracker when they have time and lust to do it. This is better than posting everything through email, because then everybody need to read all the stuff from other cases. Of course somebody can see an email faster, but the things are better documented in an issue tracker. And maybe the issue tracker has an option to inform people through email when they really want it. But I do not know GitHub in detail, maybe there is one who has more experience and knows how to setup such a GitHub for public use with multiple members. Is there some core developer, that knows more about Squeak like me and which has more a position like an admin, he can do that possibly.
> >>
> >> I have created simply a Github account while I used Pharo, but this Github is my private account. I think I am not the right person to create a Github account for the whole Squeak community and control all the member profiles. Maybe there is a core developer, that can make this decision better than me. And maybe we can create a Github account with more admin accounts, so that it is really a community Github account and not a one-private-person-account.
> >>
> >> Jörg
> >>
> >>> Am 18.02.2022 um 19:53 schrieb tim Rowledge <tim at rowledge.org>:
> >>>
> >>>
> >>>
> >>>> On 2022-02-17, at 10:10 AM, Jörg Belger <unique75 at web.de> wrote:
> >>>>
> >>>> I added issue 613, thanks for this hint.
> >>>>
> >>>> Why is there no professional issue tracking for the Squeak Smalltalk code?
> >>>
> >>> Well, we have an ancient and much ignored Mantis bug tracker that has slid slowly into history, largely because it is a bit onerous to use; and ..
> >>>
> >>>> Maybe a chief Squeak officer
> >>>
> >>> ... we don't have one. If you have any ideas at all about how we could afford to employ somebody to spend their time managing the bugs and tasks, well, we'd be thrilled to hear of them. Everything done here is done by volunteers providing their time. That means anything that is onerous tends to not get done unless somebody develops a bad case of noblesse oblige.
> >>>
> >>> tim
> >>> --
> >>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> >>> Fractured Idiom:- J'Y SUIS, J'Y PESTES - I can stay for the weekend
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>