[Pharo-project] Process questions about configurationOf….

Guillermo Polito guillermopolito at gmail.com
Sat Jan 7 18:49:50 CET 2012

Some thoughts that comes to my mind:

- What if the project depends on external stuff? Let's put dbxtalk:  for
the tests running ok, you have to install opendbx + several databases.
And since it's a pain to perform a special install for every project with
special necessities, this kind of projects should be considered as a
special case perhaps...

- And what if the project has no test cases? hehe

 - Should the process care about overrides between packages? :/  We can
have conflicting projects...


BTW, If a person takes care of publishing the package to the metarepo
inbox, isn't it enough to consider the package to be included as it is?
It's a lot of work to certify each project :/


On Sat, Jan 7, 2012 at 1:25 PM, Stéphane Ducasse
<stephane.ducasse at inria.fr>wrote:

> >>
> > Some questions out of curiosity since I'm not yet involved in publishing
> any packages
> >
> > Is there some way to tag for the submitter to be emailed the Jenkins
> results?  Perhaps a method like 'emailJenkinsResultsTo:' inthe
> configuration or alternatively Jenkins might unzip the mcz to directly
> search the ".st" files for a specific string.
> >
> > As I understand it, the ConfigurationOfXXX contains information on
> multiple versions and multiple platforms.  Thinking ahead to when there is
> a MetaRepoForPharo14, are there any concerns keeping two versions of
> ConfigurationOfXXX in sync between the two repos?  For example when an
> application releases a new version for Pharo13, do you only update the
> ConfigurationOfXXX in MetaRepoForPharo13? And do you then end up with
> further forks for ConfigurationOfXXX on other platforms?
> the idea is that you should keep the master in your project and publish to
> the repository when you want to make
> your configuration available.
> > What about a single repository (if not the existing MetacelloRepository
> then perhaps MetaRepoCI), which Jenkins processes and then if that single
> file works for Pharo13 it is copied toMetaRepoForPharo13 and if it works
> for Pharo14 then it is copied to toMetaRepoForPharo14.  Other platforms can
> do the same.  That way the application developer has to manage a single
> location.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120107/cda9d345/attachment.htm>

More information about the Pharo-project mailing list