On 21.12.2009, at 03:30, Milan Zimmerman (JIRA) wrote:
[ http://tracker.squeakland.org/browse/SQ-638 ]
Milan Zimmerman commented on SQ-638:
Hi Bert: I see you already discovered this recording problem long time ago. Recording is not a problem on Windows (I tested it today as well), so it seems either Unix VM or XO distribution specific. So maybe we do not need equivalent ticket here...
Maybe not. But maybe too ;)
[ As a side note, it's preferable to have those kinds of discussion on the mailing list rather than in the bug tracker. It's good practice: http://producingoss.com/en/bug-tracker-usage.html ]
If the Squeakland developers want to know which problems exist with Etoys, then we expect the Squeakland bug tracker to be conclusive. So for that reason alone I'd think a ticket is warranted.
The main question is who will see to it this gets fixed. It does sound like a VM problem to me. But since Etoys is one of the rare Squeak applications recording sound, we should keep track of it. Not necessarily fixing it ourselves, but trying to get the right people looking into it.
So the problem was observed on a XO using the OLPC operating system. So dev.laptop.org is the right place to report the bug. But that OS is a Fedora derivative, and it uses the Fedora Squeak packages. So the OLPC Etoys maintainer should file an upstream bug with Fedora. But Fedora gets Etoys and Squeak from somewhere else, so Fedora's Etoys maintainer should file an upstream bug with Squeakland. Then someone at Squeakland who feels responsible for Linux VM issues with Etoys should file and monitor an upstream bug with squeak.org. Once a fix is provided it flows downstream from Squeak to Fedora to OLPC. (it's even a bit more complicated because the VM and Etoys come from different places, but you get the idea)
Taking short cuts to this longwinded procedure is necessary in the short term because Etoys is just now getting established as a regular part of Linux distributions. But building that network of maintainers is essential. There are just too many ways to get Etoys to be able to track it all on our own:
http://wiki.squeakland.org/display/sq/Bug+Tracking
The situation is different on Mac and Windows where so far Squeakland is the only "vendor". But IMHO Squeakland cannot and should not try to be the vendor for Etoys on Linux. It's a Good Thing (tm) there are no RPMs nor DEBs on Squeakland for Etoys 4, because that would interfere with and undermine the efforts of maintainers in the distros. This of course should be mentioned on the downloads page, and a tar ball should be provided so that packagers know where to start and get new releases from.
- Bert -
On December 21, 2009, Bert Freudenberg wrote:
On 21.12.2009, at 03:30, Milan Zimmerman (JIRA) wrote:
[ http://tracker.squeakland.org/browse/SQ-638 ]
Milan Zimmerman commented on SQ-638:
Hi Bert: I see you already discovered this recording problem long time ago. Recording is not a problem on Windows (I tested it today as well), so it seems either Unix VM or XO distribution specific. So maybe we do not need equivalent ticket here...
Maybe not. But maybe too ;)
[ As a side note, it's preferable to have those kinds of discussion on the mailing list rather than in the bug tracker. It's good practice: http://producingoss.com/en/bug-tracker-usage.html ]
yes, I agree :)
If the Squeakland developers want to know which problems exist with Etoys, then we expect the Squeakland bug tracker to be conclusive. So for that reason alone I'd think a ticket is warranted.
The main question is who will see to it this gets fixed. It does sound like a VM problem to me. But since Etoys is one of the rare Squeak applications recording sound, we should keep track of it. Not necessarily fixing it ourselves, but trying to get the right people looking into it.
So the problem was observed on a XO using the OLPC operating system. So dev.laptop.org is the right place to report the bug. But that OS is a Fedora derivative, and it uses the Fedora Squeak packages. So the OLPC Etoys maintainer should file an upstream bug with Fedora. But Fedora gets Etoys and Squeak from somewhere else, so Fedora's Etoys maintainer should file an upstream bug with Squeakland. Then someone at Squeakland who feels responsible for Linux VM issues with Etoys should file and monitor an upstream bug with squeak.org. Once a fix is provided it flows downstream from Squeak to Fedora to OLPC.
yes...
(it's even a bit more complicated because the VM and Etoys come from different places, but you get the idea)
Taking short cuts to this longwinded procedure is necessary in the short term because Etoys is just now getting established as a regular part of Linux distributions. But building that network of maintainers is essential. There are just too many ways to get Etoys to be able to track it all on our own:
I think you are right - and nice to have the bug lists in one place.
So, in conclusion, for the near future, bugs like https://dev.laptop.org/ticket/9724 should be also added to http://tracker.squeakland.org/browse . If you still think so :) , please add it or let me know and I will add it. At least that is the single bug list Squeakland observers track, can vote on etc.
The situation is different on Mac and Windows where so far Squeakland is the only "vendor". But IMHO Squeakland cannot and should not try to be the vendor for Etoys on Linux. It's a Good Thing (tm) there are no RPMs nor DEBs on Squeakland for Etoys 4, because that would interfere with and undermine the efforts of maintainers in the distros.
I definitely agree with that. I know you have been helping a lot to engage them.
This of course should be mentioned on the downloads page, and a tar ball should be provided so that packagers know where to start and get new releases from.
We mention a bit about distros here:
http://wiki.squeakland.org/display/sq/Creating+Etoys+Release+for+Squeakland%... to-go
But yes, it should be on the download page ... and we should remove the old versions from the download page, I think. But I don't know what exactly to put in the tarball. If one of us remembers, let's bring it up on the next dev irc meeting.
Milan
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
I think we have an important bug regarding the information we convey for third party Deb or Rpm packagers.
As I reported months ago, the Squeakland download page is very far to be perfect for a free software packager because it brings *no* information about the source code. As you may know, each binary package comes with its source package. As it is now, it is not clear at all for a thrird party packager where are the sources.
For an external viewer, it looks like Etoys pretend to be free software but it is not (source code not there) or it looks like someone want to protect some asset (Is it a post Sophie trauma?)
I wrote a proposal (far to be perfect) for the download page, but Tim removed it because of translation issue in the seb server, which I agree because the way it was rendered was far to be perfect) While writing the proposal, I also received unfriendly feedback from Berg for tiny details.
Guys, do you have any problem providing information about the source code? It is a tiny effort to clarify this situation.
Hilaire
2009/12/23 Milan Zimmermann milan.zimmermann@sympatico.ca
The situation is different on Mac and Windows where so far Squeakland is the only "vendor". But IMHO Squeakland cannot and should not try to be
the
vendor for Etoys on Linux. It's a Good Thing (tm) there are no RPMs nor DEBs on Squeakland for Etoys 4, because that would interfere with and undermine the efforts of maintainers in the distros.
I definitely agree with that. I know you have been helping a lot to engage them.
This of course should be mentioned on the downloads page, and a tar ball should be provided so that packagers know where to start and get new releases from.
We mention a bit about distros here:
http://wiki.squeakland.org/display/sq/Creating+Etoys+Release+for+Squeakland%... to-gohttp://wiki.squeakland.org/display/sq/Creating+Etoys+Release+for+Squeakland%2C+OLPC%2C+or+Etoys-%0Ato-go
But yes, it should be on the download page ... and we should remove the old versions from the download page, I think. But I don't know what exactly to put in the tarball. If one of us remembers, let's bring it up on the next dev irc meeting.
On 23.12.2009, at 08:40, Hilaire Fernandes wrote:
I think we have an important bug regarding the information we convey for third party Deb or Rpm packagers.
As I reported months ago, the Squeakland download page is very far to be perfect for a free software packager because it brings *no* information about the source code. As you may know, each binary package comes with its source package. As it is now, it is not clear at all for a thrird party packager where are the sources.
For an external viewer, it looks like Etoys pretend to be free software but it is not (source code not there) or it looks like someone want to protect some asset (Is it a post Sophie trauma?)
I wrote a proposal (far to be perfect) for the download page, but Tim removed it because of translation issue in the seb server, which I agree because the way it was rendered was far to be perfect) While writing the proposal, I also received unfriendly feedback from Berg for tiny details.
Guys, do you have any problem providing information about the source code? It is a tiny effort to clarify this situation.
Agreed. Based on what you wrote, here is what I came up with to explain the source situation on the download page:
=========== Squeak Etoys is made of two parts: a cross-platform part, written in Squeak Smalltalk, and the Squeak Virtual Machine to run it. The Virtual Machine is an independent project, please see squeakvm.org for its source code. All other source code is included with the regular download. Simply press Cmd-comma or Alt-comma to open the Smalltalk IDE tools. To contribute, please go to dev.squeakland.org. ===========
Additionally, there should be a "source" tarball - or we simply point to these ones:
http://download.sugarlabs.org/sources/sucrose/glucose/etoys/
- Bert -
On December 23, 2009, Bert Freudenberg wrote:
On 23.12.2009, at 08:40, Hilaire Fernandes wrote:
I think we have an important bug regarding the information we convey for third party Deb or Rpm packagers.
As I reported months ago, the Squeakland download page is very far to be perfect for a free software packager because it brings *no* information about the source code. As you may know, each binary package comes with its source package. As it is now, it is not clear at all for a thrird party packager where are the sources.
For an external viewer, it looks like Etoys pretend to be free software but it is not (source code not there) or it looks like someone want to protect some asset (Is it a post Sophie trauma?)
I wrote a proposal (far to be perfect) for the download page, but Tim removed it because of translation issue in the seb server, which I agree because the way it was rendered was far to be perfect) While writing the proposal, I also received unfriendly feedback from Berg for tiny details.
Guys, do you have any problem providing information about the source code? It is a tiny effort to clarify this situation.
Agreed. Based on what you wrote, here is what I came up with to explain the source situation on the download page:
=========== Squeak Etoys is made of two parts: a cross-platform part, written in Squeak Smalltalk, and the Squeak Virtual Machine to run it. The Virtual Machine is an independent project, please see squeakvm.org for its source code. All other source code is included with the regular download. Simply press Cmd-comma or Alt-comma to open the Smalltalk IDE tools. To contribute, please go to dev.squeakland.org. ===========
That sounds good to me with a minor nitpick, hopefully making it clearer:
=========== Squeak Etoys is made of two parts: a cross-platform part (image), written in Squeak Smalltalk, and the Squeak Virtual Machine to run it. The Squeak Virtual Machine is an independent project, please see squeakvm.org for its source code.
All source code for the cross-platform part is included in the downloaded installers below and also in the tarball. When running Etoys, simply press Cmd-comma or Alt-comma to open the Smalltalk IDE tools, which allow to view and modify the cross-platform source code. To contribute, please go to dev.squeakland.org. ===========
If there is a reasonable agreement (to whatever text we end up with), who can edit the download page to put it there?
Additionally, there should be a "source" tarball - or we simply point to these ones:
http://download.sugarlabs.org/sources/sucrose/glucose/etoys/
FWIW I would just point to those.
Milan
- Bert -
On 23.12.2009, at 05:35, Milan Zimmermann wrote:
So, in conclusion, for the near future, bugs like https://dev.laptop.org/ticket/9724 should be also added to http://tracker.squeakland.org/browse . If you still think so :) , please add it or let me know and I will add it. At least that is the single bug list Squeakland observers track, can vote on etc.
Yes, please create a ticket.
Also, some bug tracking systems allow to monitor upstream/downstream tickets in an automated way. I have never worked with this but it sounds useful, beats manual polling for sure.
- Bert -
On December 23, 2009, Bert Freudenberg wrote:
On 23.12.2009, at 05:35, Milan Zimmermann wrote:
So, in conclusion, for the near future, bugs like https://dev.laptop.org/ticket/9724 should be also added to http://tracker.squeakland.org/browse . If you still think so :) , please add it or let me know and I will add it. At least that is the single bug list Squeakland observers track, can vote on etc.
Yes, please create a ticket.
Done:
http://tracker.squeakland.org/browse/SQ-641
Also, some bug tracking systems allow to monitor upstream/downstream tickets in an automated way. I have never worked with this but it sounds useful, beats manual polling for sure.
Makes sense, but I have not used it either.
Milan
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Hilaire Fernandes -
Milan Zimmermann