What are the best practices for an open source project with Pharo?

CONTENTS DELETED

Le 14/9/16 à 15:22, julius a écrit :
> I'm new to Smalltalk,

welcome :)

>   I did the Inria MOOC and really like the way of how to
> construct applications.

Tx
> Still I wonder how development teams approach
> development with Pharo.
> Currently I'm thinking of implementing a small idea of mine with Pharo since
> Seaside felt quite nice when I experimented a bit. The project would need to
> be open source because I want to apply for funding at a initiative that only
> supports open source projects. But then I don't have the feeling that the
> Monticello approach is the most inviting way to get funding or contributors
> considering everyone is used to Github.
Start by building something then you will see if people comes.
Moose and Seaside are large open-source projects are people developed
using Monticello
without problem. By the end of the year we will migrate everything to
github.
And by that time you can benefit from it.

> I found now the guide to Git with Pharo by Peter Uhnak (thanks for writing
> that post!) so maybe this would be a good solution...
>
> Searching for best practices I read about some projects that make sure
> developers always get a new image every day, how could that be implemented
> without too much hassle of needing a server with some kind of build system.
You can request an account on our Jenkins server and you create a job
and you can donwload it
using the pharolauncher. You contributors can then take the latest version
commit changes and updtae the configuration and the job will cretae
automatically
a new image for the next cycle.
> *tl;dr*: how could and should I approach the development of an open source
> project with Pharo, considering acceptance of Monticello usage and sharing
> of pharo images?

You provide a configurationOf and people can take an image like the
seaside one
and load your code using the configurationOf and they can commit to your
repo.
You can either have a
     readonly repo
and an   inbox
and you do the merging. the inbox acts as a pull request.

This is how we manage Pharo and pharo reasonably complex :)

>
>
>
> --
> View this message in context: http://forum.world.st/What-are-the-best-practices-for-an-open-source-project-with-Pharo-tp4915559.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

On Wed, Sep 14, 2016 at 9:22 PM, julius <[hidden email]> wrote:
I wouldn't expect developers to religiously download a new image every
day.  (But I'd be curious to learn of a documented workflow doing
this.)  One of the great features of Pharo is the persistency of the
Image and its just as easy to update to the latest code using
Monticello or github, with the additional benefit that you get a diff
of changes to review.   The main benefits of daily image builds are CI
running unit tests that include the latest Pharo changes, having a
stake in the ground of a working system for "new" developers to get up
an running, and keeping a deployable end-user product up to date.  I
personally tend to stick with one Image for a while on one task, and
jump to the latest image any time I would be wanting to start with a
fresh image anyway.

> how could that be implemented
> without too much hassle of needing a server with some kind of build system.

Do you mean to avoid setting up a server scratch yourself, or even not
using someone else's server? Inria (who host several of Pharo's core
dev team) graciously provide a CI service for the community.
https://ci.inria.fr/

> *tl;dr*: how could and should I approach the development of an open source
> project with Pharo, considering acceptance of Monticello usage and sharing
> of pharo images?

Stef's answer here is good.

cheers -ben

CONTENTS DELETED