Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl... ;)
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable - either the issue is important, and it must/will be reopened - or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService
(class
inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Back to the original bug, I've fixed it in trunk.
Repairing broken SoundService default requires a new script (done). Now I don't remember, should I create an update map to make sure that this script is evaluated?
2018-04-06 22:20 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/ Labours_of_Hercules#Fifth_labour:_Augean_stables ;)
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService
(class
inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the
bug
report is only here for the moment.
On 06.04.2018, at 23:12, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Back to the original bug, I've fixed it in trunk.
OK :) thanks -t
Repairing broken SoundService default requires a new script (done). Now I don't remember, should I create an update map to make sure that this script is evaluated?
2018-04-06 22:20 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl... ;)
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com: Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Hi Nicolas,
thank you. I think I will also override #default: to ensure that only behaviors are stored. At the moment, the meaning of #default changed without taking take of #default: so that "self default: self default" still works. No updateMap/script should be required if we make sure that ReleaseBuilder also resets all AppRegistries.
Best, Marcel Am 06.04.2018 23:12:43 schrieb Nicolas Cellier nicolas.cellier.aka.nice@gmail.com: Back to the original bug, I've fixed it in trunk.
Repairing broken SoundService default requires a new script (done).
Now I don't remember, should I create an update map to make sure that this script is evaluated?
2018-04-06 22:20 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com [mailto:nicolas.cellier.aka.nice@gmail.com]>:
Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl... [https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl...] ;)
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close.
Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout).
Other teams including Pharo have such a policy.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks.
But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis <lewis@mail.msen.com [mailto:lewis@mail.msen.com]>:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
+1, Nice to see that my exact thoughts are already in trunk, it's magic ;)
2018-04-08 11:46 GMT+02:00 Marcel Taeumel marcel.taeumel@hpi.de:
Hi Nicolas,
thank you. I think I will also override #default: to ensure that only behaviors are stored. At the moment, the meaning of #default changed without taking take of #default: so that "self default: self default" still works. No updateMap/script should be required if we make sure that ReleaseBuilder also resets all AppRegistries.
Best, Marcel
Am 06.04.2018 23:12:43 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>: Back to the original bug, I've fixed it in trunk.
Repairing broken SoundService default requires a new script (done). Now I don't remember, should I create an update map to make sure that this script is evaluated?
2018-04-06 22:20 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com>:
Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/ Labours_of_Hercules#Fifth_labour:_Augean_stables ;)
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService
(class
inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the
bug
report is only here for the moment.
On 7 April 2018 at 04:20, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl... ;)
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Note that this is done by a bot, so there is no judgement of the importance of the issue. The judgement comes from the initiator re-opening it.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
Personally, when my Pharo issues are auto-closed sometimes I think "Whoops, I really do mean to get back to that" and re-open it, and othertimes I think "Nah! It never happened to me twice, not *really* important" and I leave it closed. The latter doesn't discourage me from logging issues. Its there to be found if its a common issue and it gains additional comments indicating it should be reopened if no-one yet dealt with it.
cheers -ben
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Le sam. 7 avr. 2018 à 05:51, Ben Coman btc@openinworld.com a écrit :
On 7 April 2018 at 04:20, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi David, Just a small brook for washing yet another
https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl...
;)
My advice would be to inspect the entries updated these last two years,
and
if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Note that this is done by a bot, so there is no judgement of the importance of the issue. The judgement comes from the initiator re-opening it.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
Personally, when my Pharo issues are auto-closed sometimes I think "Whoops, I really do mean to get back to that" and re-open it, and othertimes I think "Nah! It never happened to me twice, not *really* important" and I leave it closed. The latter doesn't discourage me from logging issues. Its there to be found if its a common issue and it gains additional comments indicating it should be reopened if no-one yet dealt with it.
cheers -ben
Hi Ben, That's the right attitude. But remember that I'm emotional, it helps to perceive things or obscure others when it gets personal.
But, in the end, Pharo team is right: accumulation of rotten issues is
not
sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
On Fri, Apr 06, 2018 at 10:20:12PM +0200, Nicolas Cellier wrote:
Hi David, Just a small brook for washing yet another https://en.wikipedia.org/wiki/Labours_of_Hercules#Fifth_labour:_Augean_stabl... ;)
LOL!
And you are right.
Dave
My advice would be to inspect the entries updated these last two years, and if still relevant confirm (or fix) else close. Fortunately, there are not so much of them.
Then I would close all the rest (resolution = timeout). Other teams including Pharo have such a policy.
Generally, I hate when my opened issues are closed like that, because I mostly don't use Pharo, so I consider these as pure gifts. There is a side effect that I'm not encouraged to report anymore, and I rarely reopen them, because I have no time to check. There is no such thing as gift-support-service.
But, in the end, Pharo team is right: accumulation of rotten issues is not sustainable
- either the issue is important, and it must/will be reopened
- or no one cares and the issue can be closed.
If Heracles himself wants to inspect and resolve the timed-out issues, he would just have to set a filter with a few clicks. But there's no hurry, the Augean stables had to wait 30 years...
2018-04-06 21:58 GMT+02:00 David T. Lewis lewis@mail.msen.com:
Nicolas,
It is really good to see those Mantis issues being addressed. Thank you!
Dave
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService
(class
inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Nicolas, we have a 5.2 project now and I looking all which seems a bug for made a bug report in Mantis mention the mail. First I test on 5.2 AllInOne for see if bug shows. I hear the sound so you think this is stilla issue ?
Edgar @morplenauta
On 06/04/2018, 16:52, "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com wrote:
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Hi Edgar, this issue is fixed now. Maybe once a year, or maybe less, I inspect if there are interesting reports, because we have a few links still pointing to it. I then try to close some. But personnally I would not open an issue here. I think that Mantis is almost dead. I would opt for a github issue tracker, coupled with travis driven tests. Somewhere under https://github.com/squeak-smalltalk maybe?
2018-07-17 13:24 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
Nicolas, we have a 5.2 project now and I looking all which seems a bug for made a bug report in Mantis mention the mail. First I test on 5.2 AllInOne for see if bug shows. I hear the sound so you think this is stilla issue ?
Edgar @morplenauta
On 06/04/2018, 16:52, "Nicolas Cellier" <nicolas.cellier.aka.nice@ gmail.com> wrote:
Hi Marcel, Tobias, I encountered a bug, when playing a sound, the default SoundService (class inst var) was not a class (BasedSoundService) but an instance (a BasedSoundService).
Why? Because, there is a TileMorphTest>>setUp that remember which is the default, then tries to restore it in tearDown. It used to work.
But, in between, SoundService default and defaultOrNil have been re-defined so as to answer an instance rather than a class.
Thus, when we play the tests, we can no more play the sounds...
I hesitate to open a Mantis issue, no one read nor close them, so the bug report is only here for the moment.
Only if nobody use some is dead. Mantis could be not the most exciting bug tracker , but works. And now git is under Microsoft control, personally is risky use it. Once I build a Mantis clone all in Squeak,maybe is time to resurrect it
Edgar @morplenauta
On 17/07/2018, 18:14, "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com wrote:
Hi Edgar, this issue is fixed now. Maybe once a year, or maybe less, I inspect if there are interesting reports, because we have a few links still pointing to it. I then try to close some. But personnally I would not open an issue here. I think that Mantis is almost dead. I would opt for a github issue tracker, coupled with travis driven tests. Somewhere under https://github.com/squeak-smalltalk maybe?
2018-07-18 12:47 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
Only if nobody use some is dead. Mantis could be not the most exciting bug tracker , but works.
Activity is close to zero, so it's mostly abandonned. It's not administrated. No-one harvest the reports. Feature-wise, it's not integrated with source code version/continuous integration, while github is (if only we decide it...)
And now git is under Microsoft control, personally is risky use it.
It's immensely more risky to maintain our own architecture
Once I build a Mantis clone all in Squeak,maybe is time to resurrect it
Even more risky ;) No offense :)
Edgar @morplenauta
On 17/07/2018, 18:14, "Nicolas Cellier" <nicolas.cellier.aka.nice@ gmail.com> wrote:
Hi Edgar, this issue is fixed now. Maybe once a year, or maybe less, I inspect if there are interesting reports, because we have a few links still pointing to it. I then try to close some. But personnally I would not open an issue here. I think that Mantis is almost dead. I would opt for a github issue tracker, coupled with travis driven tests. Somewhere under *https://github.com/squeak-smalltalk https://github.com/squeak-smalltalk* maybe?
On 18/07/2018, 09:49, "Nicolas Cellier" nicolas.cellier.aka.nice@gmail.com wrote:
It's not administrated.
No-one harvest the reports.
Just recently I have developer right's and begin to have 5.2 related stuff . Also dig this mail list to found bugs still happenning and made a Mantis issue report. (so I found this old and solved)
Once I build a Mantis clone all in Squeak,maybe is time to resurrect it
Even more risky ;) No offense :)
I do what could. No offenses. As for git, could be one option if all agree (and use)
Edgar @morplenauta
2018-07-18 15:11 GMT+02:00 Edgar J. De Cleene edgardec2005@gmail.com:
On 18/07/2018, 09:49, "Nicolas Cellier" <nicolas.cellier.aka.nice@ gmail.com> wrote:
It's not administrated.
No-one harvest the reports.
Just recently I have developer right's and begin to have 5.2 related stuff . Also dig this mail list to found bugs still happenning and made a Mantis issue report. (so I found this old and solved)
Once I build a Mantis clone all in Squeak,maybe is time to resurrect it
Even more risky ;) No offense :)
I do what could.
It's not at all personal, I could do lot worse than you :) It's about our capacity to collectively develop and maintain a solid infrastructure, I mean a socially efficient one.
No offenses. As for git, could be one option if all agree (and use)
git is not the keypoint. It's rather good, scales rather well but is very complex (many ways to achieve the same thing, many command line options, etc...). github is the key. It's the social thing.
Edgar @morplenauta
Nicolas Cellier wrote
github is the key. It's the social thing.
+1. Things like issue/commit linking, and the ability to discuss changes inline in the diff are powerful (and fun). For me the game changer was one-click forking…
Old workflow: find an awesome - but abandoned - library. Have a small fix that makes it work again. But no access to mcz repo :/ Start a days?weeks?months?-long hunt for the maintainer. Ultimately realize that they have left the community and…
New workflow: Click "Fork" and happily continue coding. Bonus points for clicking "New Pull Request" so the original project can merge if interested.
----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
On Wed, Jul 18, 2018 at 09:25:48PM -0500, Sean P. DeNigris wrote:
Nicolas Cellier wrote
github is the key. It's the social thing.
+1. Things like issue/commit linking, and the ability to discuss changes inline in the diff are powerful (and fun). For me the game changer was one-click forking???
Old workflow: find an awesome - but abandoned - library. Have a small fix that makes it work again. But no access to mcz repo :/ Start a days?weeks?months?-long hunt for the maintainer. Ultimately realize that they have left the community and???
New workflow: Click "Fork" and happily continue coding. Bonus points for clicking "New Pull Request" so the original project can merge if interested.
Thanks Sean, that is a very good explanation :-)
Dave
On 19 July 2018 at 10:25, Sean P. DeNigris sean@clipperadams.com wrote:
Nicolas Cellier wrote
github is the key. It's the social thing.
+1. Things like issue/commit linking, and the ability to discuss changes inline in the diff are powerful (and fun). For me the game changer was one-click forking…
Old workflow: find an awesome - but abandoned - library. Have a small fix that makes it work again. But no access to mcz repo :/ Start a days?weeks?months?-long hunt for the maintainer. Ultimately realize that they have left the community and…
New workflow: Click "Fork" and happily continue coding. Bonus points for clicking "New Pull Request" so the original project can merge if interested.
And more importantly, you don't have to feel guilty about forking since its the normal workflow to contribute to a project. In old days it can be hard (I've heard) to track changes between forks. So here is my favourite git/github view... https://github.com/OpenSmalltalk/opensmalltalk-vm/network which tracks all changes in all forks. That doesn't work so well between git-providers, but maybe one day changes might be federated between providers.
cheers -ben
On Wed, Jul 18, 2018 at 07:47:47AM -0300, Edgar J. De Cleene wrote:
Only if nobody use some is dead. Mantis could be not the most exciting bug tracker , but works. And now git is under Microsoft control, personally is risky use it. Once I build a Mantis clone all in Squeak,maybe is time to resurrect it
Edgar @morplenauta
Edgar,
Can you please be the administrator for Mantis? We do not currently have an administrator, but I think that Tobias knows how to give you the necessary access. You have the support of the Squeak oversight board (CCed), we discussed this at our meeting today.
Tobias,
If possible, could you please give Mantis administrator rights to Edgar? I do not know how this works, but I think that you mentioned previously that you could do this. If you need another person to help from an administrative point of view (server access on the box) you may add me in that role, but Edgar should be the actual Mantis administrator on bugs.squeak.org.
Thanks to both of you,
Dave
p.s. This does not mean that the board is advocating Mantis, just that we want Edgar to have the tools that he needs and has asked for. Please carry on discussing bug trackers in the original thread :-)
Tobias give me rights Thanks Tobias. !
Sent from my iPhone
On 18 Jul 2018, at 21:38, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jul 18, 2018 at 07:47:47AM -0300, Edgar J. De Cleene wrote: Only if nobody use some is dead. Mantis could be not the most exciting bug tracker , but works. And now git is under Microsoft control, personally is risky use it. Once I build a Mantis clone all in Squeak,maybe is time to resurrect it
Edgar @morplenauta
Edgar,
Can you please be the administrator for Mantis? We do not currently have an administrator, but I think that Tobias knows how to give you the necessary access. You have the support of the Squeak oversight board (CCed), we discussed this at our meeting today.
Tobias,
If possible, could you please give Mantis administrator rights to Edgar? I do not know how this works, but I think that you mentioned previously that you could do this. If you need another person to help from an administrative point of view (server access on the box) you may add me in that role, but Edgar should be the actual Mantis administrator on bugs.squeak.org.
Thanks to both of you,
Dave
p.s. This does not mean that the board is advocating Mantis, just that we want Edgar to have the tools that he needs and has asked for. Please carry on discussing bug trackers in the original thread :-)
Edgar J. De Cleene-3 wrote
And now git is under Microsoft control, personally is risky use it.
With all the importers/exporters between the major hosts (GitHub, GitLab, BitBucket), etc. I'm sure sure this is an actual issue in practice. I've made at least 3 switches as prices/features have evolved and they were all pretty much one-click.
----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
squeak-dev@lists.squeakfoundation.org
-
Ben Coman -
David T. Lewis -
Edgar De Cleene -
Edgar J. De Cleene
-
Marcel Taeumel -
Nicolas Cellier -
Sean P. DeNigris -
Tobias Pape