Re: [Sugar-devel] Requiring test coverage for new code
The first patch with tests landed just now! I'd say it went pretty smoothly. Thanks to Walter for trying this out first :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
And the tests are doing their job :) http://buildbot.sugarlabs.org/builders/raring-amd64-quick/builds/189/steps/shell_4/logs/stdio On 9 June 2013 14:30, Daniel Narvaez dwnarv...@gmail.com wrote: The first patch with tests landed just now! I'd say it went pretty smoothly. Thanks to Walter for trying this out first :) -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On 05/18/2013 07:36 PM, Manuel Quiñones wrote: 2013/5/18 Daniel Narvaez dwnarv...@gmail.com: On 17 May 2013 15:13, Daniel Narvaez dwnarv...@gmail.com wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness Summarizing the positions expressed in the thread Simon would like 1. Marco would do 2 and then consider if we can move to 1. Manuel would like 2. Walter would be happy with 2, as long as there is guidance. Gonzalo and James doesn't seem happy about requiring tests at all. I suppose Simon and Manuel needs to talk and make a decision. These are the times when it's nice to have maintainers and not be one :P I have expressed my opinion favouring testing, so 2 or 1 would be fine for me. I would say, let's start with 2: Every feature patch, then we can move to 1 gradually. I would also like to express my view on contributions. We should not block any valuable contribution. Suppose that a child finds a bug, then modifies a file in the XO and then sends the modified file to us in a email with a brief description. Very welcome! I would say. For this kind of occasional contributions, we (regular contributors) should take over and do the procedure by ourselves, and also add the testing. Yes, that sounds very good to me. If this guy sends in another patch we can start to guide him through the review process. For a one-hit-patch-wonder we can keep things simple. Also as Walter pointed, indeed we need to provide guidance to the contributors. And the review process is good for that. -- .. manuq .. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On Sat, May 18, 2013 at 06:21:54PM +0200, Daniel Narvaez wrote: Marco would do 2 and then consider if we can move to 1. Manuel would like 2. Walter would be happy with 2, as long as there is guidance. Gonzalo and James doesn't seem happy about requiring tests at all. No, I don't mind requiring tests, but I don't think the reasons you gave were supported by evidence. I wanted to see that evidence, that's all. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On Sat, May 18, 2013 at 02:36:13PM -0300, Manuel Quiñones wrote: [...] I would also like to express my view on contributions. We should not block any valuable contribution. Suppose that a child finds a bug, then modifies a file in the XO and then sends the modified file to us in a email with a brief description. Very welcome! I would say. For this kind of occasional contributions, we (regular contributors) should take over and do the procedure by ourselves, and also add the testing. +1 Include in your definition of child any developer who has the time to discover and fix the root of the problem but not the time to do learn git, avoid injecting unwanted changes, make a patch, mail it, register for github, make a pull request, follow up on lack of action on pull request, translate review comments into their own language, overcome the disheartening, rebase the patch, fight with git again, succeed in a pull request, get a late review about pep8 failure, repeat the whole process, then go back and add tests, raise a ticket because the release engineer wants one for tracking reasons, ... only to find the next release doesn't have the fix. ;-) -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On 17 May 2013 15:13, Daniel Narvaez dwnarv...@gmail.com wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness Summarizing the positions expressed in the thread Simon would like 1. Marco would do 2 and then consider if we can move to 1. Manuel would like 2. Walter would be happy with 2, as long as there is guidance. Gonzalo and James doesn't seem happy about requiring tests at all. I suppose Simon and Manuel needs to talk and make a decision. These are the times when it's nice to have maintainers and not be one :P ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
2013/5/18 Daniel Narvaez dwnarv...@gmail.com: On 17 May 2013 15:13, Daniel Narvaez dwnarv...@gmail.com wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness Summarizing the positions expressed in the thread Simon would like 1. Marco would do 2 and then consider if we can move to 1. Manuel would like 2. Walter would be happy with 2, as long as there is guidance. Gonzalo and James doesn't seem happy about requiring tests at all. I suppose Simon and Manuel needs to talk and make a decision. These are the times when it's nice to have maintainers and not be one :P I have expressed my opinion favouring testing, so 2 or 1 would be fine for me. I would also like to express my view on contributions. We should not block any valuable contribution. Suppose that a child finds a bug, then modifies a file in the XO and then sends the modified file to us in a email with a brief description. Very welcome! I would say. For this kind of occasional contributions, we (regular contributors) should take over and do the procedure by ourselves, and also add the testing. Also as Walter pointed, indeed we need to provide guidance to the contributors. And the review process is good for that. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On Saturday, May 18, 2013 02:36:13 PM Manuel Quiñones wrote: 2013/5/18 Daniel Narvaez dwnarv...@gmail.com: On 17 May 2013 15:13, Daniel Narvaez dwnarv...@gmail.com wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch I like the second level. New feature patches should include testing scripts, and those scripts could be run after applying bugfixes too. I would also like to express my view on contributions. We should not block any valuable contribution. +1 Cheers, Daniel Francis. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
I don't know if my opinion matters, but I would also suggest 100% code coverage. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
+1 to adding tests to all new features, but some guidance on what these tests should look like is necessary. -walter On Fri, May 17, 2013 at 9:16 AM, Simon Schampijer si...@schampijer.de wrote: How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
Oh sorry, I suppose I should have made that clear :) I'm talking about automated tests, we have a few examples of them in the tree https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests https://github.com/sugarlabs/sugar/tree/master/tests https://github.com/sugarlabs/sugar-build/tree/master/tests On 17 May 2013 15:16, Simon Schampijer si...@schampijer.de wrote: How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
I'm happy to provide guidance on this (for as much time free time I have available for sugar). On 17 May 2013 15:23, Walter Bender walter.ben...@gmail.com wrote: +1 to adding tests to all new features, but some guidance on what these tests should look like is necessary. -walter On Fri, May 17, 2013 at 9:16 AM, Simon Schampijer si...@schampijer.de wrote: How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
IMO being a small team makes it an even better idea :) If you get used to it, I think you write solid new code faster _with_ tests than without. I disagree we don't have a regression problem. Just think of the settings stuff that has been broken for months. Also we are scared to refactor stuff because it might cause bugs. My feeling is that we don't find many regressions just because we don't do enough human testing. I admit the small team argument might be valid against doing 1. Writing tests for existing code helps with regression but it is time consuming. And given the general quality of the code base slowing down bug fixes might not be a good idea. I really don't have a strong feeling about this tough, I guess we have maintainers to take this kind of decisions :P On 17 May 2013 15:36, Gonzalo Odiard gonz...@laptop.org wrote: May be I am old fashion, but requesting mandatory automated tests for all the changes is not a good idea. We are a small team. And we don't have a problem of regressions. May be, with the new web api, with the many changes we will have in the next months, is a good idea. Gonzalo On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez dwnarv...@gmail.comwrote: Oh sorry, I suppose I should have made that clear :) I'm talking about automated tests, we have a few examples of them in the tree https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests https://github.com/sugarlabs/sugar/tree/master/tests https://github.com/sugarlabs/sugar-build/tree/master/tests On 17 May 2013 15:16, Simon Schampijer si...@schampijer.de wrote: How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
Sorry for not answering yet, I was in doubt.because of the raising the bar consequence. I really missed unit-testings in Sugar when the GTK3 port was made. I considered starting doing them at that time, but looked like a lot of work. Adding testing to an already written system can be a pain. But if we progressively do it, that would be great. So I vote for 2. And for the html sugar, we should do full coverage testing. 2013/5/17 Gonzalo Odiard gonz...@laptop.org: May be I am old fashion, but requesting mandatory automated tests for all the changes is not a good idea. We are a small team. And we don't have a problem of regressions. May be, with the new web api, with the many changes we will have in the next months, is a good idea. Gonzalo On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Oh sorry, I suppose I should have made that clear :) I'm talking about automated tests, we have a few examples of them in the tree https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests https://github.com/sugarlabs/sugar/tree/master/tests https://github.com/sugarlabs/sugar-build/tree/master/tests On 17 May 2013 15:16, Simon Schampijer si...@schampijer.de wrote: How does the test coverage looks like? Human testing or automated tests? Thanks, Simon On 05/17/2013 03:13 PM, Daniel Narvaez wrote: Simon, Manuel, any feedback about this? I see a few possible levels 1 Everything, bugfixes included 2 Every feature patch 3 Every patch to the new html/javascript code 4 Nothing, leave it to the contributor willingness I'm opposed to 4 :) I tend to think we should do 2, because a lot of new code is landing and the more code without tests we need to maintain the worst the quality situation will get. I guess 3 would also be a possibility if we want to try it out and increase gradually. On 13 May 2013 00:28, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). I can add a paragraph about it to sugar-docs, if we have consensus. A few details: * What to do with patches which have been already submitted? I think it really depends on the patch, so I'd leave it to the reviewer discretion. * Should this apply to bug fixes? I tend to think it should, we are not in a particularly active bug fixing period now, so it's a good time to start with those too. * Cannot apply to javascript code yet, because the infra is not in place. Though writing the infra is on the short time priorities, so this should change soon. * Cannot apply to activities because we are missing infra bits. It would not be too hard to add them, but I think we should focus on html activities now. -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On 17 May 2013 15:53, Manuel Quiñones ma...@laptop.org wrote: And for the html sugar, we should do full coverage testing. You mean make check enforced 100% coverage? :) I would love it. You proposed it, so people hate should be directed to you! I did it with a project I and always felt sort of guilty about people swearing while trying to cover every single little code branch :P ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On Mon, May 13, 2013 at 12:28:58AM +0200, Daniel Narvaez wrote: I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). Why? How has the quality tracked? Or is it that you have too many contributions and you need to raise the bar to slow them down? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Requiring test coverage for new code
On Monday, 13 May 2013, James Cameron wrote: On Mon, May 13, 2013 at 12:28:58AM +0200, Daniel Narvaez wrote: I'd like to propose to make it a requirement, enforced by code reviews, to provide good test coverage when submitting new code. It will raise the bar for contributions but it's essential if we want to improve quality (and I think we have to). Why? How has the quality tracked? Unfortunately we don't have very objective means to measure quality. Very little testing is done, even less bug triaging, as William pointed out in the bug tracking thread. So I'm afraid I can only report about my personal experience. I've tried a couple of times to use Sugar as my desktop and I've noticed pretty trivial bugs that you would expect to be fixed the day after they are introduced. I'd say subjectively quality was obviously very low. Multiple sections of the settings panel has been completely broken since they was ported to gtk3, until Walter fixed them a few days ago. The frequency of backtraces in our logs is so high that it makes development difficult, not quite a proof of poor quality, but certainly not a good symptom. The collaboration framework, which is an essential part of the user experience, is completely unreliable. Activities still randomly fails to start, seen both in automated testing and in use. Fortunately I don't think I need to prove our quality is pretty bad to assert automated tests are a good development practice. And the fact that very little human testing is done, is a good reason to increase automated one. Or is it that you have too many contributions and you need to raise the bar to slow them down? I cant tell if you are being sarcastic here or not. If you are I think that's a bit ingenerous, I've been working a lot to lower the barriers and with some success. Anyway, no, I want the barriers to be as low as possible, but not at expense of code quality and good development practices. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
