5 Mar
2014
5 Mar
'14
11:25 a.m.
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
5 Mar
5 Mar
11:52 a.m.
On Wed, Mar 5, 2014 at 11:25 AM, Diego Lont <diego.lont(a)delware.nl> 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
1:25 p.m.
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
1:45 p.m.
On Wed, Mar 5, 2014 at 1:25 PM, Stephan Eggermont <stephan(a)stack.nl> 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
2:05 p.m.
Hi Damien,
On 05 Mar 2014, at 13:45, Damien Cassou <damien.cassou(a)gmail.com> wrote:
On Wed, Mar 5, 2014 at 1:25 PM, Stephan Eggermont
<stephan(a)stack.nl> 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.
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.
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
4:56 p.m.
On Wed, Mar 5, 2014 at 2:05 PM, Diego Lont <diego.lont(a)delware.nl> 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
10 Mar
10 Mar
4:46 p.m.
New subject: Internal flags treatment?
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
3697
days inactive
3702
days old
6 comments
4 participants
participants (4)
-
Damien Cassou -
Diego Lont -
Friedrich Dominicus -
Stephan Eggermont