Broken Pier

Damien,

Please check on regular basis if you can still run Pier and if it looks good. This is the second time you broke Pier and I do not want to debug your code.

With other words: use an image that has Pier and all add ons loaded when you do your re-factorings!

Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Wed, Mar 5, 2014 at 11:25 AM, Diego Lont <[hidden email]> wrote:
> Please check on regular basis if you can still run Pier and if it looks good. This is the second time you broke Pier and I do not want to debug your code.
>
> With other words: use an image that has Pier and all add ons loaded when you do your re-factorings!


I can imagine this is frustrating for you. But, I'm not a stupid
random clicker. How can I make sure I'm not breaking anything by just
randomly clicking here and there? I trust tests. I can see multiple
options, please comment:

- someone interested in Pier increases test coverage of the parts he
cares about (this can be web-based tests with something like Selenium
as well as unit tests). I will subscribe to any additional CI job that
gets created to get informed when I break something and I will fix it
if I can.

- someone interested in Pier changes the Pier configuration to use a
fixed version of Pillar and not the latest one. Then, when this guy
wants the latest Pillar features and fixes, he can change the
dependency version and fix Pier (this is the standard process for all
developments that depend on an external library). In this case I will
help this guy use the latest Pillar.

- as a last resort, someone interested in Pier could setup an
automatic deployment of a full pier-based website (on seasidehosting
for example) where I could randomly click from time to time.

Any other idea?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Damien,

I strongly disagree with the notion that other people should do work
because you broke something. That is exactly what I feared when
you first proposed making Pier-Model a separate project.

I think the basic issue is that your development needs to happen
in an image where you have Pier loaded with all add-ons.
You could of course write integration tests for your API changes,
but I think just loading Pier might be easier for now.

We don’t have issues with the difficult problems, we have with code
that simply doesn’t load because classes were moved, or doesn’t run
because the inheritance hierarchy was changed. None of which would
have happened had you developed in an image where Pier is loaded.

I’m looking forward to having web-based testing integrated in CI.
That is something we cannot organise from outside Inria.

Stephan
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Wed, Mar 5, 2014 at 1:25 PM, Stephan Eggermont <[hidden email]> wrote:
> I think the basic issue is that your development needs to happen
> in an image where you have Pier loaded with all add-ons.

actually, I think that's a good idea. Do you have a CI job that
creates a Pier 3 + all add-ons + Pillar bleeding edge images? Please
give me the url so I can do what you propose (I can help you if there
is none already).

Nevertheless, this can only work on the short term. I can't imagine
that tomorrow I will have to work on an image that contains many
applications that depend on Pillar and fix them all and feel
responsible for all. Currently, I know only 2 applications that depend
on Pillar (namely Pier and Marina) and a few web pages and books so
this approach could work. In the long term, only automated tests will
save you.

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Hi Damien,

On 05 Mar 2014, at 13:45, Damien Cassou <[hidden email]> wrote:

> On Wed, Mar 5, 2014 at 1:25 PM, Stephan Eggermont <[hidden email]> wrote:
>> I think the basic issue is that your development needs to happen
>> in an image where you have Pier loaded with all add-ons.
>
> actually, I think that's a good idea. Do you have a CI job that
> creates a Pier 3 + all add-ons + Pillar bleeding edge images? Please
> give me the url so I can do what you propose (I can help you if there
> is none already).

Yes, there is. It is the CI job that builds PierAddons. It works for the stable version, but not for the development version (that is based on Pier development and thus Pillar development). We are currently working on fixing some add ons that fail in Pharo 3.

> Nevertheless, this can only work on the short term. I can't imagine
> that tomorrow I will have to work on an image that contains many
> applications that depend on Pillar and fix them all and feel
> responsible for all. Currently, I know only 2 applications that depend
> on Pillar (namely Pier and Marina) and a few web pages and books so
> this approach could work. In the long term, only automated tests will
> save you.

Yes, in the long term automated tests are better. But Pier is an existing framework where you pull out a part of the functionality from. As the organisation on smalltakhub implies, all projects in the group Pier belong together and are maintained together. All developers want to make changes to Pier should keep that in mind.

Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Wed, Mar 5, 2014 at 2:05 PM, Diego Lont <[hidden email]> wrote:
> Yes, there is. It is the CI job that builds PierAddons. It works for the stable version, but not for the development version (that is based on Pier development and thus Pillar development). We are currently working on fixing some add ons that fail in Pharo 3.


please keep me informed

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm."
Winston Churchill

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

I've some flags which are partly internal, partly interesing to the
users.
e.g I have a daily books log and I have a special log called
Abfallregister (waste register)
and flags like besonders überwachungsbedürftig

you can see some of the "used" translations ins QCMigrateArticle

and yes some Articles are supposed to be placed on Lager (storage
places) others are not (well I'm not fully sure if there is one Article
where on does not need a storage place, but it's currently the case)

Should this flags be placed in the QCArticle of some other place?

Regards
Friedrich


--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki