Re: [Sugar-devel] My GSoC Proposal for activity unit tests
Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.comwrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Regarding Social Help project
I took a look at two of the webservices - Facebook and PutLocker. Now, Facebook provides an access token that can be used to log the user in via third-party clients. As far as I can see, Discourse does not provide such access tokens. The Facebook access token being used is here: https://github.com/walterbender/facebook/blob/master/extensions/webservice/facebook/account.py#L53 However, in the PutLocker implementation, sugar is *actually storing plain-text passwords! *Look here: https://github.com/ignaciouy/sugar-putlocker/blob/master/extensions/webservice/sugarupload/account.py#L43 This, IMHO, is a big mistake. Many users tend to keep the same password on different websites - and having the plain-text password stored in a file is nothing short of giving away your account to anyone who uses your laptop. I do not know why this is being used but I refuse to use this method. This leaves us again with *any one* of these three options: 1. Modify the browse activity as I mentioned in the last post. 2. Store the hashes of the password and use one of the authentication hooks to log the user in as mentioned in the last post. 3. Or, and I personally do not like this option, get the users to log in to discourse via Facebook. My primary reason for not liking this is that we'll be tying up authentication to a non-free (as in freedom) service. But, we can go through with this, if this appeals to the community. Personally, I like #1 and #2. But, the final decision on this is not mine to make since I'm a very new member of the sugar community. So, let us discuss this issue here and reach a decision soon so that I can finish writing my proposal. Thanks On Thu, Mar 13, 2014 at 12:13 AM, Gonzalo Odiard godi...@sugarlabs.orgwrote: Has you read about webservices support in Sugar? http://wiki.sugarlabs.org/go/WebServices http://wiki.sugarlabs.org/go/Features/Web_services Gonzalo On Wed, Mar 12, 2014 at 3:26 PM, Prasoon Shukla prasoon92.i...@gmail.comwrote: Hi Frederick, Sam. Well, the way I imagine this project is that a user can launch into a Discourse discussion in a Browse activity. This activity can then be shared as any other activity - this part will not require any other specific changes to be made (if I understand your request correctly). We can, however, add links to the discussions on Discourse on the sugar-network website in the relevant places. Anyway, I tried to think of a few ways in which we can preserve a user session across discussions. Finally, I've decided on the following flow: 1. Get the user to register the first time - this process is very easy and we can pick email directly from sugar. Then, the part before the '@' can be the default username for Discourse (this the user can of course change). The user will need to enter the password though. 2. Discourse will create a session for the user and send the browser the session information(cookies). Now, and this is a crucial point, I'll need to modify the browse activity to add a method that can will return session information (the session cookie) to the calling process. I'll call this method via DBus to retrieve the this information. We'll then store this in a configuration file. 3. The user can then close the browser. When the user opens the browser again: - we'll check if the session cookie exists. - if it does, then we do not need to write this cookie to the browser. - otherwise, we'll retrieve the session cookie from the config file and write it to the browser - this will need another method to be added to the browse activity. This will log the user back in seamlessly without the need to fill in authentication information. Now, if we go through with this implementation strategy, then our only concern at this stage will be whether the getCookie and setCookie can be implemented in the browse activity. Of course, getting and setting cookies can be done via JS in any webkit browser. So, I think it shouldn't be difficult to do this. Now the decision remains whether to proceed with this course or not (in which case we'll probably need to talk to discourse devs about how to log users in directly with a PBKDF2 hashhttps://meta.discourse.org/t/why-does-discourse-use-pbkdf2/2934. Btw, they're using OmniAuth https://github.com/intridea/omniauth for authentication and they also provide quite a few authentication hooks to tweak authentication according to our needs, so it shouldn't be too hard ...). @Sam, @Frederick: Please let me know of a decision on this. Also, @Frederick, let me know if we need anything specific to sugar-network other than what I mentioned earlier. Thanks Prasoon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___
Re: [Sugar-devel] Feature freeze
On Thu, Mar 13, 2014 at 12:37 AM, Manuel Quiñones ma...@laptop.org wrote: in my humble opinion, I would also like to see the feature freeze delayed. several features are almost done. How long away is almost done? A few days, weeks? While I'm happy to see it delayed I want the delay defined so it doesn't roll on into an indefinite mess. I don't believe that is fair on either the release manager or the community at large. Daniel would you be amicable to stretching it out by a month so we have one more round of dev releases before entering freeze? To the people writing and reviewing is that enough rime to review and land the remaining features? Peter I see our community is still rearranging, and we need to put more effort in reviews. considering the load of PRs, we should embrace pair-reviewing. 2014-03-09 22:25 GMT-03:00 Daniel Narvaez dwnarv...@gmail.com: On 10 March 2014 01:48, Gonzalo Odiard godi...@sugarlabs.org wrote: On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: For what it's worth it would be a -1 from me. I would be fine to delay a bit to fix important bugs, but not to add more features, it seems to go completely against the rationale of time based releases. But that's just my opinion. Would be against the time based release, if the propose would be postpone it indefinitely. I disagree. From https://wiki.gnome.org/ReleasePlanning/TimeBased -- Although we agree on rough aims for each major release, and attempt to achieve those aims, GNOME releases are time-based rather than feature-based. A roughly 6-month release cycle allows us to coordinate development of the features that have actually been implemented, allowing us to maintain the quality of the overall release without delaying everything because of one or two features. If a feature is not ready in time then the developers must not wait long to put it in the next major release. We have found that this encourages both high quality and rapid development compared to feature-based release schedules. -- IMO delaying feature freeze is very clearly against that definition, in many ways. Many projects working with time based releases, like libreoffice, gnome or fedora adjust the schedules if they consider worth it. I honestly don't remember any of these projects making a decision to delay *feature* freeze two weeks after the deadline. I could be wrong of course, I have not followed every single releases of them. More importantly, even if they did, it wouldn't mean their decision was consistent with the time based release schedule rationale. Sometimes it's worth to make compromises. To articulate my point a bit more 1 Delaying feature freeze after the deadline is obviously against time based release definition and rationale. 2 I don't see anything special with the current situation that would suggest we should compromise on our time based approach. ___ 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature freeze
On Thu, Mar 13, 2014 at 4:50 AM, Peter Robinson pbrobin...@gmail.comwrote: On Thu, Mar 13, 2014 at 12:37 AM, Manuel Quiñones ma...@laptop.org wrote: in my humble opinion, I would also like to see the feature freeze delayed. several features are almost done. How long away is almost done? A few days, weeks? While I'm happy to see it delayed I want the delay defined so it doesn't roll on into an indefinite mess. I don't believe that is fair on either the release manager or the community at large. Daniel would you be amicable to stretching it out by a month so we have one more round of dev releases before entering freeze? To the people writing and reviewing is that enough rime to review and land the remaining features? I agree, we want postpone the freeze, but define a date too. I proposed add 3 weeks to the previous schedule, but looking the time we need to decide, maybe one month have more sense. Gonzalo Peter I see our community is still rearranging, and we need to put more effort in reviews. considering the load of PRs, we should embrace pair-reviewing. 2014-03-09 22:25 GMT-03:00 Daniel Narvaez dwnarv...@gmail.com: On 10 March 2014 01:48, Gonzalo Odiard godi...@sugarlabs.org wrote: On Sun, Mar 9, 2014 at 9:40 PM, Daniel Narvaez dwnarv...@gmail.com wrote: For what it's worth it would be a -1 from me. I would be fine to delay a bit to fix important bugs, but not to add more features, it seems to go completely against the rationale of time based releases. But that's just my opinion. Would be against the time based release, if the propose would be postpone it indefinitely. I disagree. From https://wiki.gnome.org/ReleasePlanning/TimeBased -- Although we agree on rough aims for each major release, and attempt to achieve those aims, GNOME releases are time-based rather than feature-based. A roughly 6-month release cycle allows us to coordinate development of the features that have actually been implemented, allowing us to maintain the quality of the overall release without delaying everything because of one or two features. If a feature is not ready in time then the developers must not wait long to put it in the next major release. We have found that this encourages both high quality and rapid development compared to feature-based release schedules. -- IMO delaying feature freeze is very clearly against that definition, in many ways. Many projects working with time based releases, like libreoffice, gnome or fedora adjust the schedules if they consider worth it. I honestly don't remember any of these projects making a decision to delay *feature* freeze two weeks after the deadline. I could be wrong of course, I have not followed every single releases of them. More importantly, even if they did, it wouldn't mean their decision was consistent with the time based release schedule rationale. Sometimes it's worth to make compromises. To articulate my point a bit more 1 Delaying feature freeze after the deadline is obviously against time based release definition and rationale. 2 I don't see anything special with the current situation that would suggest we should compromise on our time based approach. ___ 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 -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposing review 0.102 schedule
On 11 March 2014 02:56, Walter Bender walter.ben...@gmail.com wrote: Daniel, I think that what is behind this request is that there are some deployments (Australia and Uruguay) where a few weeks delay wouldn't make much difference but carrying a bunch of patches downstream for another release cycle will mean a lot of work. I don't think Gonzalo made this request lightly. I don't think it would mean a lot of work. It would only matter for the next 7 weeks. During this time development is going to slow down, it might even almost stall like we have seen with 0.99. We are unlikely to hit many conflicts, and they should be quick to sort out as long as you manage your sources in git. I think most likely managing those patches is going to require less time then we collectively spent on this thread :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposing review 0.102 schedule
On 11 March 2014 03:46, Gonzalo Odiard godi...@sugarlabs.org wrote: Daniel, I don't want put you in a uncomfortable situation. All of us are pretty loaded. I don't see how modifying the schedule can prejudice you or other in the team. If this change means more work for other, then no deal. I will shut up, and load my own charge. If nobody is harm, then I don't see why we can't discuss this issue. I expect we as a community, and specially who are more involved in the work, can talk openly, and take decisions, or even review our decisions, without somebody feel uncomfortable for that. You are making it sound like I'm trying to shut you and the community up. I hope it's obvious to everyone that's not my intention. The only reason I'm uncomfortable is that I'm supposed to take a decision on this while I'm in total disagreement with the rest of the community. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature freeze
On 13 March 2014 08:50, Peter Robinson pbrobin...@gmail.com wrote: To the people writing and reviewing is that enough rime to review and land the remaining features? Just fyi I'm unlikely to have time to review major patches. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Pippy-58
Activity Homepage: http://activities.sugarlabs.org/addon/4041 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28911/pippy-58.xo Release notes: 58 BUG FIX: typo in alert callback name Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] My GSoC Proposal for activity unit tests
Etoys is not in Python, I think. How will you write tests? Will UI tests work on it? On Thu, Mar 13, 2014 at 11:36 AM, Gaurav Parida gparid...@gmail.com wrote: Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.comwrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Feature freeze
On 13 March 2014 08:50, Peter Robinson pbrobin...@gmail.com wrote: Daniel would you be amicable to stretching it out by a month so we have one more round of dev releases before entering freeze? Sorry for the delay on closing down this issue, I have been busy. I'll try to keep it short so that we can all go back at work asap. I think we are taking the wrong decision in the wrong way here. I have yet to see a rationale for proposing a delay. We are apparently trying to save some time for some deployment team, and I'd argue we are not even saving much. I don't like this kind of ad hoc decisions, as an upstream we should be thinking less about our own short time priorities and more about potential contributors. I'm not in love with time based releases, as I have pointed out in the past, but we should be reconsidering our release approach as a whole, if it's not good enough, rather than making an exception for not particularly good reasons. That said, I think the community consensus is pretty clear, I'm the only one in disagreement. So please someone send me the new release dates and I'll update the schedule. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] My GSoC Proposal for activity unit tests
I don't think so, it's not using gtk. On 13 March 2014 13:22, Sai Vineet saivinee...@gmail.com wrote: Etoys is not in Python, I think. How will you write tests? Will UI tests work on it? On Thu, Mar 13, 2014 at 11:36 AM, Gaurav Parida gparid...@gmail.comwrote: Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.comwrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ 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] My GSoC Proposal for activity unit tests
Probably etoys would be out of the list of activities to test. Gonzalo On Thu, Mar 13, 2014 at 9:33 AM, Daniel Narvaez dwnarv...@gmail.com wrote: I don't think so, it's not using gtk. On 13 March 2014 13:22, Sai Vineet saivinee...@gmail.com wrote: Etoys is not in Python, I think. How will you write tests? Will UI tests work on it? On Thu, Mar 13, 2014 at 11:36 AM, Gaurav Parida gparid...@gmail.comwrote: Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.comwrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ 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 -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] My GSoC Proposal for activity unit tests
We could ask the Etoys maintainers to build us some sort of dbus interface we can work with. But I agree, it should be out of the first batch of programs we test. regards. -walter On Thu, Mar 13, 2014 at 8:36 AM, Gonzalo Odiard godi...@sugarlabs.org wrote: Probably etoys would be out of the list of activities to test. Gonzalo On Thu, Mar 13, 2014 at 9:33 AM, Daniel Narvaez dwnarv...@gmail.com wrote: I don't think so, it's not using gtk. On 13 March 2014 13:22, Sai Vineet saivinee...@gmail.com wrote: Etoys is not in Python, I think. How will you write tests? Will UI tests work on it? On Thu, Mar 13, 2014 at 11:36 AM, Gaurav Parida gparid...@gmail.com wrote: Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.com wrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ 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 -- Gonzalo Odiard SugarLabs - Learning Software for children -- 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] My GSoC Proposal for activity unit tests
They could support the atk dbus interface (if I remember correctly it's not gtk only) but it would likely be a lot of work... On 13 March 2014 13:55, Walter Bender walter.ben...@gmail.com wrote: We could ask the Etoys maintainers to build us some sort of dbus interface we can work with. But I agree, it should be out of the first batch of programs we test. regards. -walter On Thu, Mar 13, 2014 at 8:36 AM, Gonzalo Odiard godi...@sugarlabs.org wrote: Probably etoys would be out of the list of activities to test. Gonzalo On Thu, Mar 13, 2014 at 9:33 AM, Daniel Narvaez dwnarv...@gmail.com wrote: I don't think so, it's not using gtk. On 13 March 2014 13:22, Sai Vineet saivinee...@gmail.com wrote: Etoys is not in Python, I think. How will you write tests? Will UI tests work on it? On Thu, Mar 13, 2014 at 11:36 AM, Gaurav Parida gparid...@gmail.com wrote: Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.com wrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ 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 -- Gonzalo Odiard SugarLabs - Learning Software for children -- 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] My GSoC Proposal for activity unit tests
Question: is there no other way to write UI tests? ATK is a pain. And if I'm not wrong ATK is a accessibility related thing, so we're using the using the wrong way to test? On Mar 13, 2014 6:42 PM, Daniel Narvaez dwnarv...@gmail.com wrote: They could support the atk dbus interface (if I remember correctly it's not gtk only) but it would likely be a lot of work... On 13 March 2014 13:55, Walter Bender walter.ben...@gmail.com wrote: We could ask the Etoys maintainers to build us some sort of dbus interface we can work with. But I agree, it should be out of the first batch of programs we test. regards. -walter On Thu, Mar 13, 2014 at 8:36 AM, Gonzalo Odiard godi...@sugarlabs.org wrote: Probably etoys would be out of the list of activities to test. Gonzalo On Thu, Mar 13, 2014 at 9:33 AM, Daniel Narvaez dwnarv...@gmail.com wrote: I don't think so, it's not using gtk. On 13 March 2014 13:22, Sai Vineet saivinee...@gmail.com wrote: Etoys is not in Python, I think. How will you write tests? Will UI tests work on it? On Thu, Mar 13, 2014 at 11:36 AM, Gaurav Parida gparid...@gmail.com wrote: Hi, Uptill now I have been successful in installing all the activities except etoys(there is some file opeing error in the log) and I can't find the repository named image as specfied in the list of the activities at http://download.sugarlabs.org/sources/sucrose/fructose/ I thought that after the exams I would bug people on IRC and get the etoys issue fixed and run it. @ignacio On Thu, Mar 13, 2014 at 5:23 AM, Ignacio Rodríguez nachoe...@gmail.com wrote: I like you'r apply, but by the way.. How do you do with Etoys? This is really weird! -- Ignacio Rodríguez. Have I missed something? I am guessing that etoys is not at all supprted or what? Thanks, Gaurav ___ 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 -- Gonzalo Odiard SugarLabs - Learning Software for children -- 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] Feature freeze
On Thu, Mar 13, 2014 at 9:31 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 March 2014 08:50, Peter Robinson pbrobin...@gmail.com wrote: Daniel would you be amicable to stretching it out by a month so we have one more round of dev releases before entering freeze? Sorry for the delay on closing down this issue, I have been busy. I'll try to keep it short so that we can all go back at work asap. I think we are taking the wrong decision in the wrong way here. I have yet to see a rationale for proposing a delay. We are apparently trying to save some time for some deployment team, and I'd argue we are not even saving much. I don't like this kind of ad hoc decisions, as an upstream we should be thinking less about our own short time priorities and more about potential contributors. I'm not in love with time based releases, as I have pointed out in the past, but we should be reconsidering our release approach as a whole, if it's not good enough, rather than making an exception for not particularly good reasons. I see your point, but I think is better separate the issue of extend these release cycle, to start a discussion about how we will manage the release cycle in the future. Maybe we should define a time, after 0.102, to review our release strategy. That said, I think the community consensus is pretty clear, I'm the only one in disagreement. So please someone send me the new release dates and I'll update the schedule. After ask manuq, and reading other comments here, I propose: 0.101.4 - 04/01/14 - Feature Freeze 0.101.5 - 05/01/14 - String, UI, API freeze 0.102.0 - 06/01/14 - Final release Now, back to work! We need do good use of this time! -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] My GSoC Proposal for activity unit tests
On 13 March 2014 14:20, Sai Vineet saivinee...@gmail.com wrote: Question: is there no other way to write UI tests? ATK is a pain. You need some kind of out-of-process mechanism to click around, see the UI etc. I'm not sure there is anything better than atk for that. And if I'm not wrong ATK is a accessibility related thing, so we're using the using the wrong way to test? Well, dogtail, which is far as I know is the only alive test automation framework for gtk, uses ATK in the same way. Also using the accessibility toolkit for UI test is something seen in several other toolkits. You need the same kind of things... I'm not sure what is you issue with ATK exactly. The current sugar.test.uitree stuff is really low level, you could build something more friendly on it perhaps (or use dogtail even, I gave up on it because it was too complicated and racy but things might have improved now that ATK is more stable). But there might also be an issue with the amount of information ATK exposes, some of our controls doesn't quite show up in the tree I think. Though that might also be fixable, by improving our accessibility story at the same time :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.3 (unstable)
Because of some issue we had with git, the sugar tarball included a few less commits than intended. Here is a new tarball http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.101.5.tar.xz * Fix #4733 remove warning on username change * Fix issue with activity updater breaking on server errors On 8 March 2014 15:32, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, this release marks our feature freeze for 0.102. Now let's focus on bug fixing! Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.101.4.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.101.3.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.101.3.tar.xz Thanks to everyone involved! -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Weirdness in sugar git repository
Hello, thanks for reporting this. As discussed on irc, I have cherry picked and pushed the missing commits, I'm now releasing 0.101.5. It's not really clear to me how it happened. Looking at the buildbot logs, pull started breaking after my 0.101.4 commit, but looking at my bash history I was just doing git push and git push --tags. I have no idea how that could have rewrote the history. On 12 March 2014 17:51, Martin Abente martin.abente.lah...@gmail.comwrote: Hello everyone, Today I pulled the latest bits from our sugar [1] repo and saw this: [tch@tch sugar]$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From git://github.com/sugarlabs/sugar + eed15fe...88ed846 master - origin/master (forced update) * [new tag] v0.101.4 - v0.101.4 Merge made by the 'recursive' strategy. configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) That didn't look right to me, so I also checked some of the pull requests and noticed that most [2,3,4,5] of our pull requests have a lot commits that weren't there before. Could it be that someone changed the history at some point (ie., using --force)? Other ideas? tch. Refs: 1. https://github.com/sugarlabs/sugar 2. https://github.com/sugarlabs/sugar/pull/261 3. https://github.com/sugarlabs/sugar/pull/265 4. https://github.com/sugarlabs/sugar/pull/266 5. https://github.com/sugarlabs/sugar/pull/267 ___ 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
[Sugar-devel] Changes to 0.102 schedule
Hello, as proposed by Gonzalo, the schedule for 0.102 has been updated 0.101.4 - 04/01/14 - Feature Freeze 0.101.5 - 05/01/14 - String, UI, API freeze 0.102.0 - 06/01/14 - Final release http://bugs.sugarlabs.org/roadmap The most important change is that Feature freeze has moved to April 1. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changes to 0.102 schedule
Great. Will do good use of it. Gonzalo On Thu, Mar 13, 2014 at 11:38 AM, Daniel Narvaez dwnarv...@gmail.comwrote: Hello, as proposed by Gonzalo, the schedule for 0.102 has been updated 0.101.4 - 04/01/14 - Feature Freeze 0.101.5 - 05/01/14 - String, UI, API freeze 0.102.0 - 06/01/14 - Final release http://bugs.sugarlabs.org/roadmap The most important change is that Feature freeze has moved to April 1. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changes to 0.102 schedule
Sounds good! Lets keep in mind that we should to re-send some of the PRs because of the problem of with the sugar git repository history. On Thu, Mar 13, 2014 at 11:47 AM, Gonzalo Odiard godi...@sugarlabs.orgwrote: Great. Will do good use of it. Gonzalo On Thu, Mar 13, 2014 at 11:38 AM, Daniel Narvaez dwnarv...@gmail.comwrote: Hello, as proposed by Gonzalo, the schedule for 0.102 has been updated 0.101.4 - 04/01/14 - Feature Freeze 0.101.5 - 05/01/14 - String, UI, API freeze 0.102.0 - 06/01/14 - Final release http://bugs.sugarlabs.org/roadmap The most important change is that Feature freeze has moved to April 1. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] My GSoC Proposal for activity unit tests
Hi, Ok I will make the changes the changes in the timeline of the proposal. and keep the etoys as optional as of now. Yes I think dogtail is used by gnome people to do their UI tests. I'm not sure what is you issue with ATK exactly. The current sugar.test.uitree stuff is really low level, you could build something more friendly on it perhaps (or use dogtail even, I gave up on it because it was too complicated and racy but things might have improved now that ATK is more stable). But there might also be an issue with the amount of information ATK exposes, some of our controls doesn't quite show up in the tree I think. Though that might also be fixable, by improving our accessibility story at the same time :) I will get on to UI tests and see dogtail too as soon as my exams get over. My 3 Questions :) 1. What is the repo named Image as given in the link of the list of activities in fructose http://download.sugarlabs.org/sources/sucrose/fructose/ 2. Do I need to write an analysis on how tests work and how it will be done with reference to the activities in the proposal? 3. @org administrator (walter) Please review my proposal at google melange whenever you are free and give the feedback so that I could modify it before the deadline. Thanks, Gaurav On Thu, Mar 13, 2014 at 7:33 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 March 2014 14:20, Sai Vineet saivinee...@gmail.com wrote: Question: is there no other way to write UI tests? ATK is a pain. You need some kind of out-of-process mechanism to click around, see the UI etc. I'm not sure there is anything better than atk for that. And if I'm not wrong ATK is a accessibility related thing, so we're using the using the wrong way to test? Well, dogtail, which is far as I know is the only alive test automation framework for gtk, uses ATK in the same way. Also using the accessibility toolkit for UI test is something seen in several other toolkits. You need the same kind of things... I'm not sure what is you issue with ATK exactly. The current sugar.test.uitree stuff is really low level, you could build something more friendly on it perhaps (or use dogtail even, I gave up on it because it was too complicated and racy but things might have improved now that ATK is more stable). But there might also be an issue with the amount of information ATK exposes, some of our controls doesn't quite show up in the tree I think. Though that might also be fixable, by improving our accessibility story at the same time :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
