[Pharo-project] Process questions about configurationOf….

Mariano Martinez Peck marianopeck at gmail.com
Sun Jan 8 16:20:46 EST 2012


Hi Stef. I have answered what I think several times, but I will try to do
one last shoot ;)
I agree to what you say and I have some things to say and some questions:

1) For the implementation point of view, there must be an agreement between
the jenkins and the ConfigurationOf. Several things have to be set down:
WHICH VERSION to load, and for that version, which PACKAGES/GROUPS to load,
and WHICH category tests to run. So...this can be easily done as
conventions:
a) for which version, we assume #stable (if we are building in pharo images
before the current one). So say we are building in Pharo 1.3 then we always
load #stable. So developers should maintain that method. If we are then
building in Pharo 1.4, then I think we should use #bleedingEdge.  Last
option is to create a special symbol version for this special jenkins
runner.
b) for which package or group, each ConfigurationOf can just implement
#defaultPackagesToLoadInPharo13:  that answers an array with the
packages/groups to load. Another posibility is to always load a specific
group. Say we have a group called "CertifierGroup" and then we always load
that group.
c) we can just implement #testsCategoriesForPharo13 in each conf and that's
all.

That way, maintainers of ConfigurationOf only needs to keep #stable up to
date, and just implement (for example) #defaultPackagesToLoadInPharo13 and
#testsCategoriesForPharo13

2) Once the server has run and moved the conf to MetaRepoForPharo13, it is
very cool because we can then after scan the repo MetaRepoForPharo13 and
know that taking that conf, with that version and that amount of packages,
then it should work ;)

3) What happens with tests?  do we only accept 100% green tests as ok? In
Fuel for example, we like to create tests before the real code. And
moreover, we create tests to demonstrate things we don't support yet. So
sometimes we have red tests even if there is no bug, but just  a missing
thing we will do in the near future.
maybe we can have a treshlod ? say, 80% of green tests?

4) Answering to Guille, we don't care about overrides. I think each conf
will be run in a clean pharo image as the jenkins does right now. Is it
like this?

5) not as a first step, but as a future, the process of moving to
MetaRepoForPharo13, could also move ALL mzc files of all the packages in
order to be self-contained. But this is more complicated because then we
need to use #repositoryOverrides: or something like that because even if we
move mzc files our confs are pointing to another place... Or maybe we can
change the confs on the fly...anyway, this is future ;)

6) once we have this repositories, we can have tools that scan those repos
and let us load stuff from there.

7) Is this process propagated?  Say I have ConfigurationOfGlorpDBX and I
want to run this process. Such conf uses ConfigurationOfFFI. Will FFI be
processed as well as glorpDBX  or we only measure/analyzer the first one ?

8) Same as Guille? what happens with projects that do not have tests? There
is no way to certify they work.... I would put them as broken directly ;)

Sorry for the long mail.


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

> Hi guys
>
> What is the process we want?
> What I would like is
>
>        MetaRepoForPharo13Inbox were everybody can write
>                and a jenkins process that loads every published version
>                and try to load it (after we will run tests and check
> rules).
>        depending on the result the configuration is promoted
>        into
>                MetaRepoForPharo13
>        or
>                MetaRepoForPharo13Broken
>
> At the end of the month we will have one engineer working on jenkins and I
> would like to ask him
> to start to put in place this process.
>
> What do you think?
>
> Stef
>
>
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120108/d8b61b52/attachment-0001.html>


More information about the Pharo-dev mailing list