Hello, We have some issues ready that nevertheless need to be reviewed by humans: https://pharo.fogbugz.com/f/filters/45/Review We know that they do not make tests fail and even pass some code critic tests. But else? -> do they fix the problem? -> Is this a change that we can risk to do after code freeze? -> is the change good? Marcus
On 02 Jan 2014, at 15:25, Marcus Denker <marcus.denker@inria.fr> wrote:
Hello,
We have some issues ready that nevertheless need to be reviewed by humans:
https://pharo.fogbugz.com/f/filters/45/Review
We know that they do not make tests fail and even pass some code critic tests. But else?
-> do they fix the problem? -> Is this a change that we can risk to do after code freeze?
We should make 3.0 a good solid release. That also means that we have to finish what we started. I have seen some changes being rejected because of the âcode freezeâ while I also see lots of stuff being committed (for example, Komitter), sometimes with little review, that is potentially quite dangerous. So letâs be flexible and use common sense judgement, if it was a good/bad idea two months ago, it still is. I think the current phase weâre in means: letâs focus on quality and not on new stuff.
-> is the change good?
Marcus
Hi sven We got an internal discussion on this topic with the same concerns. Komitter was pushed because it does not touch existing code and because people like mariano where starting to code it in parallel. So we thought it was important for people. The idea is that we have some bugs to fix due to the changes we did in nautilus to support. Stef
That also means that we have to finish what we started.
I have seen some changes being rejected because of the âcode freezeâ while I also see lots of stuff being committed (for example, Komitter), sometimes with little review, that is potentially quite dangerous.
So letâs be flexible and use common sense judgement, if it was a good/bad idea two months ago, it still is.
I think the current phase weâre in means: letâs focus on quality and not on new stuff.
-> is the change good?
Marcus
Ok, this new to me, so I may not understand clearly. I give a try and pointed Pharo 3.0 to a Slice I know about, SLICE 12495 on PolygonMoprh. I asked for the changes implication and see a lot not related to PolygonMorph. Is it normal? Hilaire Le 02/01/2014 15:25, Marcus Denker a écrit :
Hello,
We have some issues ready that nevertheless need to be reviewed by humans:
https://pharo.fogbugz.com/f/filters/45/Review
We know that they do not make tests fail and even pass some code critic tests. But else?
-> do they fix the problem? -> Is this a change that we can risk to do after code freeze? -> is the change good?
Marcus
-- Dr. Geo http://drgeo.eu
On 02 Jan 2014, at 17:47, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Ok, this new to me, so I may not understand clearly. I give a try and pointed Pharo 3.0 to a Slice I know about, SLICE 12495 on PolygonMoprh. I asked for the changes implication and see a lot not related to PolygonMorph. Is it normal?
I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed in between, too.
Hilaire
Le 02/01/2014 15:25, Marcus Denker a écrit :
Hello,
We have some issues ready that nevertheless need to be reviewed by humans:
https://pharo.fogbugz.com/f/filters/45/Review
We know that they do not make tests fail and even pass some code critic tests. But else?
-> do they fix the problem? -> Is this a change that we can risk to do after code freeze? -> is the change good?
Marcus
-- Dr. Geo http://drgeo.eu
Le 02/01/2014 20:37, Marcus Denker a écrit :
I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed in between, too.
For me this is weird, I can't understand the logic. Merge: shows you the changes then let your merge Change: shows some other sort of changes I don't understand. -- Dr. Geo http://drgeo.eu
Changes reads Merge writes In order to make safe a potentially "dangerous" operation, the write is done in two steps so the user can confirm what is going to be written (or have a chance to check if changes are the ones expected or not and abort without modifying the code). It's functionally correct but the UI can be soooo much better with some tuning. I'll post something that might help us on this subject On Jan 2, 2014, at 9:04 PM, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Le 02/01/2014 20:37, Marcus Denker a écrit :
I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed in between, too.
For me this is weird, I can't understand the logic. Merge: shows you the changes then let your merge Change: shows some other sort of changes I don't understand.
-- Dr. Geo http://drgeo.eu
On 03 Jan 2014, at 01:01, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Changes reads Merge writes
In order to make safe a potentially "dangerous" operation, the write is done in two steps so the user can confirm what is going to be written (or have a chance to check if changes are the ones expected or not and abort without modifying the code).
It's functionally correct but the UI can be soooo much better with some tuning.
I'll post something that might help us on this subject
The whole Monticello Browser should not exist⦠Marcus
On 03 Jan 2014, at 10:32, Marcus Denker <marcus.denker@inria.fr> wrote:
On 03 Jan 2014, at 01:01, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Changes reads Merge writes
In order to make safe a potentially "dangerous" operation, the write is done in two steps so the user can confirm what is going to be written (or have a chance to check if changes are the ones expected or not and abort without modifying the code).
It's functionally correct but the UI can be soooo much better with some tuning.
I'll post something that might help us on this subject
The whole Monticello Browser should not existâ¦
amen maybe⦠someday⦠not so far⦠(?)
Marcus
On 03 Jan 2014, at 00:04, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Le 02/01/2014 20:37, Marcus Denker a écrit :
I always use âmergeâ. âChangesâ will e.g. show all the changes towards everything changed in between, too.
For me this is weird, I can't understand the logic. Merge: shows you the changes then let your merge Change: shows some other sort of changes I don't understand.
From then the change was made *other* changes have been done.
âChangeâ will show *all* differences, both the ones other integrations did to the package as well as the changes of the slice. In addition, there is still some bug that when e.g moving classes the *extending* packages are bot dirty and there might be some inconsistencies. Marcus
Le 03/01/2014 10:31, Marcus Denker a écrit :
From then the change was made *other* changes have been done.
âChangeâ will show *all* differences, both the ones other integrations did to the package as well as the changes of the slice.
In addition, there is still some bug that when e.g moving classes the *extending* packages are bot dirty and there might be some inconsistencies.
Got it. So this is simply an usability concern with misleading button text and button tooltips, or am I the only one to fell misguided? Anyway should be easily fixable, if it should be. Thanks Hilaire -- Dr. Geo http://drgeo.eu
2014/1/3 Hilaire Fernandes <hilaire.fernandes@gmail.com>
Le 03/01/2014 10:31, Marcus Denker a écrit :
From then the change was made *other* changes have been done.
âChangeâ will show *all* differences, both the ones other integrations did to the package as well as the changes of the slice.
In addition, there is still some bug that when e.g moving classes the *extending* packages are bot dirty and there might be some inconsistencies.
Got it. So this is simply an usability concern with misleading button text and button tooltips, or am I the only one to fell misguided?
Not the only one :-) I asked the very same question.
Anyway should be easily fixable, if it should be.
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
On 03 Jan 2014, at 12:04, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Le 03/01/2014 10:31, Marcus Denker a écrit :
From then the change was made *other* changes have been done.
âChangeâ will show *all* differences, both the ones other integrations did to the package as well as the changes of the slice.
In addition, there is still some bug that when e.g moving classes the *extending* packages are bot dirty and there might be some inconsistencies.
Got it. So this is simply an usability concern with misleading button text and button tooltips, or am I the only one to fell misguided?
Anyway should be easily fixable, if it should be.
yes⦠Marcus
participants (7)
-
Esteban Lorenzano -
Hilaire Fernandes -
Marcus Denker -
Nicolai Hess -
Sebastian Sastre -
Stéphane Ducasse -
Sven Van Caekenberghe