Hi guys, Now that the vacations are behind us (well, behind me at least :)), it's time to focus on converging MacRuby for its first stable release, 1.0. My goal is to release it somewhere in 2011 (the sooner the better :)). In order to smoothly achieve that goal, it's also time to accelerate the current release system and improve the way we classify and address incoming bugs reports. After talking with the others committers we decided on the following: 1) Much more frequent releases Starting from now we will release more frequently. Until we reach 1.0, releases will mostly contain bug fixes and improvements, and practically no feature. As a matter of fact, I intend to release trunk as 0.8 next week. By releasing MacRuby more frequently we hope people will also test MacRuby more frequently, and report more bugs. 2) Better bug management We have too many bugs registered in the tracker, and it's a pain to manage all of them. Starting from now, we will classify all existing bugs as well as incoming ones in two categories: for 1.0 and for later. We will then only focus on bugs for 1.0. The second step is to reduce the problem into a small test case (if applicable) then attach the #reduction keyword. Once bugs are properly reduced, we can fix them more easily. We intend to attach a keyword to bugs that seem to be easy to fix, this way new comers can help and learn how MacRuby works. 3) Bug smash days We will organize bug smash days. They will happen on an IRC channel (details forthcoming). The first one will happen this saturday, 6th December. We will have people from 3 different time zones (US west coast, Europe and Japan) on the IRC channel, and our first task will be to start managing all the bugs, using the method described above. New comers are greatly welcomed and we will make sure everyone who wants to help can help. 4) Compatibility support page The big challenge for MacRuby 1.0 is to have excellent Ruby compatibility. We currently have 2 metrics to test our Ruby compatibility: RubySpec and Rails. However it's not enough, there are lots of Ruby libraries and C extensions around that we can't afford to test by ourselves. Therefore, we intend to prepare a webpage on the website that lists Ruby libraries that are known to work with MacRuby, and those who don't run yet. We will make sure the community can easily update that page. Having an updated list of libraries that we should run should help the team fixing compatibility bugs. That's all for now, bug if you have any suggestion on how to improve the current development process, please let us know. Laurent
Great! Just want to make clear that it’s saturday the 4th of december. Looking forward to helping you all out with helping us out! And now spread the word, because there are enough tickets for everyone ;) On Nov 30, 2010, at 12:11 AM, Laurent Sansonetti wrote:
Hi guys,
Now that the vacations are behind us (well, behind me at least :)), it's time to focus on converging MacRuby for its first stable release, 1.0. My goal is to release it somewhere in 2011 (the sooner the better :)).
In order to smoothly achieve that goal, it's also time to accelerate the current release system and improve the way we classify and address incoming bugs reports. After talking with the others committers we decided on the following:
1) Much more frequent releases
Starting from now we will release more frequently. Until we reach 1.0, releases will mostly contain bug fixes and improvements, and practically no feature. As a matter of fact, I intend to release trunk as 0.8 next week. By releasing MacRuby more frequently we hope people will also test MacRuby more frequently, and report more bugs.
2) Better bug management
We have too many bugs registered in the tracker, and it's a pain to manage all of them. Starting from now, we will classify all existing bugs as well as incoming ones in two categories: for 1.0 and for later. We will then only focus on bugs for 1.0. The second step is to reduce the problem into a small test case (if applicable) then attach the #reduction keyword. Once bugs are properly reduced, we can fix them more easily. We intend to attach a keyword to bugs that seem to be easy to fix, this way new comers can help and learn how MacRuby works.
3) Bug smash days
We will organize bug smash days. They will happen on an IRC channel (details forthcoming). The first one will happen this saturday, 6th December. We will have people from 3 different time zones (US west coast, Europe and Japan) on the IRC channel, and our first task will be to start managing all the bugs, using the method described above. New comers are greatly welcomed and we will make sure everyone who wants to help can help.
4) Compatibility support page
The big challenge for MacRuby 1.0 is to have excellent Ruby compatibility. We currently have 2 metrics to test our Ruby compatibility: RubySpec and Rails. However it's not enough, there are lots of Ruby libraries and C extensions around that we can't afford to test by ourselves. Therefore, we intend to prepare a webpage on the website that lists Ruby libraries that are known to work with MacRuby, and those who don't run yet. We will make sure the community can easily update that page. Having an updated list of libraries that we should run should help the team fixing compatibility bugs.
That's all for now, bug if you have any suggestion on how to improve the current development process, please let us know.
Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
This all sounds excellent =) Travis On Mon, Nov 29, 2010 at 4:11 PM, Laurent Sansonetti <lsansonetti@apple.com> wrote:
Hi guys, Now that the vacations are behind us (well, behind me at least :)), it's time to focus on converging MacRuby for its first stable release, 1.0. My goal is to release it somewhere in 2011 (the sooner the better :)). In order to smoothly achieve that goal, it's also time to accelerate the current release system and improve the way we classify and address incoming bugs reports. After talking with the others committers we decided on the following: 1) Much more frequent releases Starting from now we will release more frequently. Until we reach 1.0, releases will mostly contain bug fixes and improvements, and practically no feature. As a matter of fact, I intend to release trunk as 0.8 next week. By releasing MacRuby more frequently we hope people will also test MacRuby more frequently, and report more bugs. 2) Better bug management We have too many bugs registered in the tracker, and it's a pain to manage all of them. Starting from now, we will classify all existing bugs as well as incoming ones in two categories: for 1.0 and for later. We will then only focus on bugs for 1.0. The second step is to reduce the problem into a small test case (if applicable) then attach the #reduction keyword. Once bugs are properly reduced, we can fix them more easily. We intend to attach a keyword to bugs that seem to be easy to fix, this way new comers can help and learn how MacRuby works. 3) Bug smash days We will organize bug smash days. They will happen on an IRC channel (details forthcoming). The first one will happen this saturday, 6th December. We will have people from 3 different time zones (US west coast, Europe and Japan) on the IRC channel, and our first task will be to start managing all the bugs, using the method described above. New comers are greatly welcomed and we will make sure everyone who wants to help can help. 4) Compatibility support page The big challenge for MacRuby 1.0 is to have excellent Ruby compatibility. We currently have 2 metrics to test our Ruby compatibility: RubySpec and Rails. However it's not enough, there are lots of Ruby libraries and C extensions around that we can't afford to test by ourselves. Therefore, we intend to prepare a webpage on the website that lists Ruby libraries that are known to work with MacRuby, and those who don't run yet. We will make sure the community can easily update that page. Having an updated list of libraries that we should run should help the team fixing compatibility bugs. That's all for now, bug if you have any suggestion on how to improve the current development process, please let us know. Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I'd like to know a bit more about the activities (and required skills) for the Bug smash days. For example, my C/C++/Objective-C skills are rather rusty and in any case, I have no knowledge about MacRuby internals... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation
On 2010-11-30, at 14:36 , Rich Morin wrote:
I'd like to know a bit more about the activities (and required skills) for the Bug smash days. For example, my C/C++/Objective-C skills are rather rusty and in any case, I have no knowledge about MacRuby internals...
I too would like to know more about what skills could be put to use. I have some knowledge, however terribly shallow, of the MRI 1.9 source, and I've skimmed parts of the MacRuby source. Otherwise I'm well familiar with most high level ruby, and I've found my share of bugs in MacRuby's more unpopular corners. I doubt I can fix anything on the Cocoa end, but I can certainly work on reductions.
I think the critical aspect of this event is to reduce and triage bugs. Just confirming bugs and finding reductions would save hours of work fir the entire team. Something we could do is to split the tickets among the online people and go one by one, confirm the bug against trunk, see if it is as reduced as possible and submit a reduction otherwise. One doesn't have to fix bugs to join the fun :) Some tickets will be marked as easy and people interested in learning the internals will be able to try hacking around. - Matt Sent from my iPhone On Nov 30, 2010, at 11:43, Caio Chassot <lists@caiochassot.com> wrote:
On 2010-11-30, at 14:36 , Rich Morin wrote:
I'd like to know a bit more about the activities (and required skills) for the Bug smash days. For example, my C/C++/Objective-C skills are rather rusty and in any case, I have no knowledge about MacRuby internals...
I too would like to know more about what skills could be put to use.
I have some knowledge, however terribly shallow, of the MRI 1.9 source, and I've skimmed parts of the MacRuby source.
Otherwise I'm well familiar with most high level ruby, and I've found my share of bugs in MacRuby's more unpopular corners.
I doubt I can fix anything on the Cocoa end, but I can certainly work on reductions.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
As Matt said, the priorities are: * check if a ticket is still valid on trunk * reduce the ticket to an as small as possible code snippet reproducing the problem * then you can optionally fix it, but this is way less important than the first two steps :) Also, there are bound to come up lots of extra things to discuss during the day in the IRC channel. So please do not shy away from taking part, know that I am amongst the people that have the same ‘problem’ of not being fluent in hacking the core of MacRuby too! :) Eloy On Tue, Nov 30, 2010 at 6:03 PM, Matt Aimonetti <mattaimonetti@gmail.com> wrote:
I think the critical aspect of this event is to reduce and triage bugs. Just confirming bugs and finding reductions would save hours of work fir the entire team.
Something we could do is to split the tickets among the online people and go one by one, confirm the bug against trunk, see if it is as reduced as possible and submit a reduction otherwise. One doesn't have to fix bugs to join the fun :) Some tickets will be marked as easy and people interested in learning the internals will be able to try hacking around.
- Matt
Sent from my iPhone
On Nov 30, 2010, at 11:43, Caio Chassot <lists@caiochassot.com> wrote:
On 2010-11-30, at 14:36 , Rich Morin wrote:
I'd like to know a bit more about the activities (and required skills) for the Bug smash days. For example, my C/C++/Objective-C skills are rather rusty and in any case, I have no knowledge about MacRuby internals...
I too would like to know more about what skills could be put to use.
I have some knowledge, however terribly shallow, of the MRI 1.9 source, and I've skimmed parts of the MacRuby source.
Otherwise I'm well familiar with most high level ruby, and I've found my share of bugs in MacRuby's more unpopular corners.
I doubt I can fix anything on the Cocoa end, but I can certainly work on reductions.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
sounds great. but isn't saturday the 4th, not the 6th? emil tin On 30/11/2010, at 00.11, Laurent Sansonetti wrote:
Hi guys,
Now that the vacations are behind us (well, behind me at least :)), it's time to focus on converging MacRuby for its first stable release, 1.0. My goal is to release it somewhere in 2011 (the sooner the better :)).
In order to smoothly achieve that goal, it's also time to accelerate the current release system and improve the way we classify and address incoming bugs reports. After talking with the others committers we decided on the following:
1) Much more frequent releases
Starting from now we will release more frequently. Until we reach 1.0, releases will mostly contain bug fixes and improvements, and practically no feature. As a matter of fact, I intend to release trunk as 0.8 next week. By releasing MacRuby more frequently we hope people will also test MacRuby more frequently, and report more bugs.
2) Better bug management
We have too many bugs registered in the tracker, and it's a pain to manage all of them. Starting from now, we will classify all existing bugs as well as incoming ones in two categories: for 1.0 and for later. We will then only focus on bugs for 1.0. The second step is to reduce the problem into a small test case (if applicable) then attach the #reduction keyword. Once bugs are properly reduced, we can fix them more easily. We intend to attach a keyword to bugs that seem to be easy to fix, this way new comers can help and learn how MacRuby works.
3) Bug smash days
We will organize bug smash days. They will happen on an IRC channel (details forthcoming). The first one will happen this saturday, 6th December. We will have people from 3 different time zones (US west coast, Europe and Japan) on the IRC channel, and our first task will be to start managing all the bugs, using the method described above. New comers are greatly welcomed and we will make sure everyone who wants to help can help.
4) Compatibility support page
The big challenge for MacRuby 1.0 is to have excellent Ruby compatibility. We currently have 2 metrics to test our Ruby compatibility: RubySpec and Rails. However it's not enough, there are lots of Ruby libraries and C extensions around that we can't afford to test by ourselves. Therefore, we intend to prepare a webpage on the website that lists Ruby libraries that are known to work with MacRuby, and those who don't run yet. We will make sure the community can easily update that page. Having an updated list of libraries that we should run should help the team fixing compatibility bugs.
That's all for now, bug if you have any suggestion on how to improve the current development process, please let us know.
Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Yup :) On 30 nov. 2010, at 18:18, Emil Tin <emil@tin.dk> wrote:
sounds great.
but isn't saturday the 4th, not the 6th?
emil tin
On 30/11/2010, at 00.11, Laurent Sansonetti wrote:
Hi guys,
Now that the vacations are behind us (well, behind me at least :)), it's time to focus on converging MacRuby for its first stable release, 1.0. My goal is to release it somewhere in 2011 (the sooner the better :)).
In order to smoothly achieve that goal, it's also time to accelerate the current release system and improve the way we classify and address incoming bugs reports. After talking with the others committers we decided on the following:
1) Much more frequent releases
Starting from now we will release more frequently. Until we reach 1.0, releases will mostly contain bug fixes and improvements, and practically no feature. As a matter of fact, I intend to release trunk as 0.8 next week. By releasing MacRuby more frequently we hope people will also test MacRuby more frequently, and report more bugs.
2) Better bug management
We have too many bugs registered in the tracker, and it's a pain to manage all of them. Starting from now, we will classify all existing bugs as well as incoming ones in two categories: for 1.0 and for later. We will then only focus on bugs for 1.0. The second step is to reduce the problem into a small test case (if applicable) then attach the #reduction keyword. Once bugs are properly reduced, we can fix them more easily. We intend to attach a keyword to bugs that seem to be easy to fix, this way new comers can help and learn how MacRuby works.
3) Bug smash days
We will organize bug smash days. They will happen on an IRC channel (details forthcoming). The first one will happen this saturday, 6th December. We will have people from 3 different time zones (US west coast, Europe and Japan) on the IRC channel, and our first task will be to start managing all the bugs, using the method described above. New comers are greatly welcomed and we will make sure everyone who wants to help can help.
4) Compatibility support page
The big challenge for MacRuby 1.0 is to have excellent Ruby compatibility. We currently have 2 metrics to test our Ruby compatibility: RubySpec and Rails. However it's not enough, there are lots of Ruby libraries and C extensions around that we can't afford to test by ourselves. Therefore, we intend to prepare a webpage on the website that lists Ruby libraries that are known to work with MacRuby, and those who don't run yet. We will make sure the community can easily update that page. Having an updated list of libraries that we should run should help the team fixing compatibility bugs.
That's all for now, bug if you have any suggestion on how to improve the current development process, please let us know.
Laurent _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi, I'd like to help out with the bugmash on saturday. I'm wondering, what will the workflow look like? Will it be possible to use github and it's systems? I think it would lower the barriers for mac rubyists (like myself) to become involved. Github has some pretty handy features like its pull request system too. Also, some visible guidelines for prospective contributors could be a good thing. https://www.macruby.org/trac/wiki/MacRubyDevelopment just says "Please file a ticket" and is buried (5 clicks by my count) from the homepage. Let me know what I can do to help. Thanks, -Arthur
+1 for using GitHub. Also, it would be great to have some sort of wiki entry on how to contribute to the project. On Tue, Nov 30, 2010 at 8:05 PM, Arthur Gunn <Arthur@gunn.co.nz> wrote:
Hi,
I'd like to help out with the bugmash on saturday. I'm wondering, what will the workflow look like? Will it be possible to use github and it's systems? I think it would lower the barriers for mac rubyists (like myself) to become involved. Github has some pretty handy features like its pull request system too.
Also, some visible guidelines for prospective contributors could be a good thing. https://www.macruby.org/trac/wiki/MacRubyDevelopment just says "Please file a ticket" and is buried (5 clicks by my count) from the homepage.
Let me know what I can do to help.
Thanks,
-Arthur _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
GitHub or BitBucket (I love Mercurial, its pretty much easier then Git, IMO) doesn't really matter but I think a switch to almost newer source control system will stop by the use of Xcode. Because Xcode is crappy and supports not distributed source control system.I switched from Java to Ruby and thanks to MacRuby I tried Xcode but hell I can understand how people are able to write code with Xcode ;-)Anyways anything is better then SVN --- Michael Jackson <mjijackson@gmail.com> schrieb am Mi, 1.12.2010: Von: Michael Jackson <mjijackson@gmail.com> Betreff: Re: [MacRuby-devel] converging for 1.0 An: "MacRuby development discussions." <macruby-devel@lists.macosforge.org> Datum: Mittwoch, 1. Dezember, 2010 06:00 Uhr +1 for using GitHub. Also, it would be great to have some sort of wiki entry on how to contribute to the project. On Tue, Nov 30, 2010 at 8:05 PM, Arthur Gunn <Arthur@gunn.co.nz> wrote:
Hi,
I'd like to help out with the bugmash on saturday. I'm wondering, what will the workflow look like? Will it be possible to use github and it's systems? I think it would lower the barriers for mac rubyists (like myself) to become involved. Github has some pretty handy features like its pull request system too.
Also, some visible guidelines for prospective contributors could be a good thing. https://www.macruby.org/trac/wiki/MacRubyDevelopment just says "Please file a ticket" and is buried (5 clicks by my count) from the homepage.
Let me know what I can do to help.
Thanks,
-Arthur _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
On 2010-12-01, at 07:45 , denny trebbin wrote:
GitHub or BitBucket (I love Mercurial, its pretty much easier then Git, IMO) doesn't really matter but I think a switch to almost newer source control system will stop by the use of Xcode. Because Xcode is crappy and supports not distributed source control system.I switched from Java to Ruby and thanks to MacRuby I tried Xcode but hell I can understand how people are able to write code with Xcode ;-)Anyways anything is better then SVN
How much can we talk about Xcode 4 wrt SCM integration? Well, I guess if you have ADC, go check it out.
On 1/12/2010, at 10:45 PM, denny trebbin wrote:
I switched from Java to Ruby and thanks to MacRuby I tried Xcode but hell I can understand how people are able to write code with Xcode ;-) Anyways anything is better then SVN
"Don't show me your tools, show me what you made with them"
participants (11)
-
Arthur Gunn
-
Caio Chassot
-
denny trebbin
-
Eloy Duran
-
Emil Tin
-
Henry Maddocks
-
Laurent Sansonetti
-
Matt Aimonetti
-
Michael Jackson
-
Rich Morin
-
Travis Kay