Re: [Sugar-devel] [IAEP] FW: Sugar 0.100 status report - April 2

[Ajay Garg]

On Thu, Apr 4, 2013 at 1:08 AM, Manuel Quiñones  wrote:

> The feature page doesn't explicitly state, but I remember it allows
> batch removal.
>

Ahh yes... it does :)


>
> http://wiki.sugarlabs.org/go/Features/Multi_selection
>
> 2013/4/3 Daniel Narvaez :
> > Adding devel and Ajay.
> >
> >
> > On 3 April 2013 19:26, Caryl Bigenho  wrote:
> >>
> >> I guess this is where this should go? Clue me in if it should be posted
> >> elsewhere.
> >>
> >> Caryl
> >>
> >> 
> >> Date: Wed, 3 Apr 2013 18:05:36 +0200
> >> Subject: Re: [IAEP] Sugar 0.100 status report - April 2
> >> From: dwnarv...@gmail.com
> >> To: cbige...@hotmail.com
> >>
> >>
> >> Hi Caryl,
> >>
> >> could you post this on the list?. I don't know the answer to your
> >> questions, but the patches author will know for sure...
> >>
> >>
> >> On 3 April 2013 02:04, Caryl Bigenho  wrote:
> >>
> >> Hi...
> >>
> >> Looks like great stuff! Adapting Sugar to run on Android opens lots of
> >> possibilities. My programming days ended long ago with Pascal, but I
> might
> >> be able to offer some suggestions as a Sugar user... here's one to
> start...
> >>
> >> For the multiple selection of items in the journal... will this also
> allow
> >> multiple deletion of entries? That would be a handy feature I have often
> >> wished were available. Also, do the selected items have to be
> consecutive?
> >> Could some be skipped over (either initially or by allowing a deselect
> of
> >> individual items that aren't wanted on the list).
> >>
> >> Caryl
> >>
> >>
> >>
> >> 
> >> Date: Wed, 3 Apr 2013 00:37:08 +0200
> >> From: dwnarv...@gmail.com
> >> To: sugar-devel@lists.sugarlabs.org
> >> CC: i...@lists.sugarlabs.org
> >> Subject: [IAEP] Sugar 0.100 status report - April 2
> >>
> >>
> >> Hello,
> >>
> >> I will try to send out regular reports about the progress of the 0.100
> >> release, weekly, bi-weekly or monthly depending on how much is
> happening.
> >>
> >> 1. A bit late, but we finally have a schedule for the release.We are not
> >> going to have a feature acceptance deadline this time. We decided to
> have
> >> that discussion early, to try and narrow the focus of the release.
> >>
> >> http://wiki.sugarlabs.org/go/0.100/Roadmap
> >>
> >> 2. In parallel some developers will keep to refine the 0.98 series. Help
> >> is welcome on that effort. While perhaps not as exciting as new
> features,
> >> bug fixing and polish is essential to good software.
> >>
> >> 3. The main goal of the 0.100 release will be to the develop an HTML5
> >> based toolkit for activities. This will facilitate running Sugar
> activities
> >> on other platforms, like Android. In addition we are planning to land
> >> several other features which has seen development in the past few months
> >>
> >> Multiple selection in the Journal
> >> http://wiki.sugarlabs.org/go/Features/Multi_selection
> >>
> >> Enhanced support for 3G modems
> >> http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support
> >>
> >> Background customization
> >> http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view
> >>
> >> Multiple home views
> >> http://wiki.sugarlabs.org/go/Features/Multiple_home_views
> >>
> >> Integration with web services
> >> http://wiki.sugarlabs.org/go/Features/Web_services
> >>
> >> Journal comments box
> >>
> http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view
> >>
> >> Icon customization
> >> http://wiki.sugarlabs.org/go/Features/Icon_Change
> >>
> >> 4. The project has always had a bit of an issue with submitted code
> being
> >> timely reviewed. The situation got worse in the last few months. This
> is a
> >> major blocker for contributions and we are trying to improve. Simon and
> >> Manuel, which currently maintains all the Glucose modules alone, are
> putting
> >> together a list of "reviewers" to help them out with the task. We are
> also
> >> trying to find review tools which will allow the process to be both
> >> trackable and visible to everyone (and hopefully a bit more pleasant
> too!).
> >> We have so far mostly experimented with a workflow based on github pull
> >> requests.
> >>
> >> 5. Walter Bender landed several patches to add a comment box to journal
> >> entries. It will be populated both by the Portfolio activity and by the
> web
> >> services integration which is being worked on. The obligatory screenshot
> >>
> >> http://wiki.sugarlabs.org/images/4/4a/FB-comments.png
> >>
> >> 6. All in all I think we made great progress planning the next release.
> >> But we will need everyone help to execute and make it a really good one.
> >>
> >> --
> >> Daniel Narvaez
> >>
> >> ___ IAEP -- It's An
> Education
> >> Project (not a laptop project!) i...@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/iaep
> >>
> >>
> >>
> >>
> >> --
> >> Daniel Narvaez
> >>
> >> ___
> >> IAEP -- It's

Re: [Sugar-devel] Reviews experiment

[Daniel Narvaez]

On 4 April 2013 00:39, James Cameron  wrote:

> > I've seen this kind of split both in Sugar and in a company I was
> > working for (I used to be on the email workflow side for a while
> > even :P). Honestly I have no idea how to go about it other than
> > following what most contributors like...  I don't know of tools that
> > solves this issue.
>
> Usually the solution is lowest-common-denominator technology choice.
>
> But I am a rarely active contributor, so if links in mail work for the
> rest of you, go for it.
>

I'm not sure it they work, which is why I'm calling this an experiment :)

Though I think time has sort of proven the email workflow doesn't work well
for our most active contributors. In fact they moved back to do reviews in
trac despite the official review process.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Reviews experiment

[James Cameron]

On Thu, Apr 04, 2013 at 12:19:45AM +0200, Daniel Narvaez wrote:
> Unfortunately this is highly subjective. What is harder for you is
> easier for me. I find it extremely frustrating to do reviews in
> gmail and there is almost no time when "I have no web interface".

Ah, I can't advise on how to use gmail over HTTP for reviews.  Perhaps
someone else can.

When I use gmail I use it over IMAP rather than HTTP.

> I've seen this kind of split both in Sugar and in a company I was
> working for (I used to be on the email workflow side for a while
> even :P). Honestly I have no idea how to go about it other than
> following what most contributors like...  I don't know of tools that
> solves this issue.

Usually the solution is lowest-common-denominator technology choice.

But I am a rarely active contributor, so if links in mail work for the
rest of you, go for it.

-- 
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] Acked-by vs Reviewed-by

[James Cameron]

That's really up to the maintainer.  If the maintainer pushes the
patch, then Acked-by may be inferred.

In general these procedures scale well to large numbers of
maintainers, contributors, and reviewers.  I'm not sure they remain
appropriate for Sugar given the size of the community at the moment.

On Thu, Apr 04, 2013 at 12:13:45AM +0200, Daniel Narvaez wrote:
> So, if I understand this correctly, every Glucose patch should have had an
> Acked-by tag, since every patch should have been approved by a maintainer
> according to our review policies. (That has not been the case)
> 
> 
> On 3 April 2013 23:50, James Cameron  wrote:
> 
> On Wed, Apr 03, 2013 at 10:07:07PM +0200, Daniel Narvaez wrote:
> > it seems that most of our patches should have a Reviewed-by tag, on the
> > contrary I see Acked-by used most of the time (at the top of the
> > sugar-toolkit-gtk3 log at least).
> >
> > Am I missing something?
> 
> I agree with others; for Glucose since I am not maintainer I would add
> Reviewed-by, but for Pippy since I am maintainer I would add Acked-by.
> 
> (If I add Acked-by to a patch, I might also push it, depending on
> whether the contributor is known to be able to push, and whether more
> work is happening right at the moment.)
>
> --
> James Cameron
> http://quozl.linux.org.au/
> 
> 
> 
> 
> --
> Daniel Narvaez

-- 
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] Reviews experiment

[Daniel Narvaez]

On 3 April 2013 23:53, James Cameron  wrote:

> On Wed, Apr 03, 2013 at 09:47:14PM +0200, Daniel Narvaez wrote:
> > 2. Reviewers will get email notifications when new patches are
> > posted. Please use the web interface to comment on the changes and
> > request fixes.
>
> Are you saying I won't be able to read the patch in e-mail, and won't
> be able reply to it with Reviewed-by, Acked-by or Tested-by?  I often
> read my mail when I have no web interface.
>
> I don't understand how making reviews harder would improve the
> probability of review.
>

Unfortunately this is highly subjective. What is harder for you is easier
for me. I find it extremely frustrating to do reviews in gmail and there is
almost no time when "I have no web interface".

I've seen this kind of split both in Sugar and in a company I was working
for (I used to be on the email workflow side for a while even :P). Honestly
I have no idea how to go about it other than following what most
contributors like... I don't know of tools that solves this issue.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Acked-by vs Reviewed-by

[Daniel Narvaez]

So, if I understand this correctly, every Glucose patch should have had an
Acked-by tag, since every patch should have been approved by a maintainer
according to our review policies. (That has not been the case)


On 3 April 2013 23:50, James Cameron  wrote:

> On Wed, Apr 03, 2013 at 10:07:07PM +0200, Daniel Narvaez wrote:
> > it seems that most of our patches should have a Reviewed-by tag, on the
> > contrary I see Acked-by used most of the time (at the top of the
> > sugar-toolkit-gtk3 log at least).
> >
> > Am I missing something?
>
> I agree with others; for Glucose since I am not maintainer I would add
> Reviewed-by, but for Pippy since I am maintainer I would add Acked-by.
>
> (If I add Acked-by to a patch, I might also push it, depending on
> whether the contributor is known to be able to push, and whether more
> work is happening right at the moment.)
>
> --
> James Cameron
> http://quozl.linux.org.au/
>



-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] f19 alpha TC3 soas and sugar-desktop fail to finish booting into f3 (home) screen

[Peter Robinson]

On Wed, Apr 3, 2013 at 8:42 PM, Manuel Quiñones  wrote:

> 2013/4/3 Thomas Gilliard :
> > Soas and sugar-desktop seem to be  unusable at the moment:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=947538
>
> Same happens in my netbook.  It stalls in the home screen.  If I
> switch to a text console and use the top command, I see a python
> process taking all the CPU.  This process is owned by liveuser user.
>
> If I can be of any help testing, bring me instructions.


Help would be useful, what instructions do you need? Run up an image and
see how you get on :-) Let me know how I can help

Peter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Usage of Signed-off-by / Acked-by - Re: Recent movement on Sugar master repository

[James Cameron]

On Wed, Apr 03, 2013 at 06:27:46PM +0200, Daniel Narvaez wrote:
> Perhaps you can explain exactly what Signed-off-by adds compared to
> the author field in tnormal cases? I know it's not much work, but it
> adds one more thing we need to request to patch submitters. I tend
> to think the simpler is the process the more patches we will get :)
> Or at least I personally get really annoyed by bureaucracy when
> submitting code.

Signed-off-by is an awareness and enthusiasm test.  If a patch arrives
without these, it means the patch was sent by someone who is so
enthusiastic about their work that they might have forgotten
something.  ;-)

I was annoyed too, but my annoyance went away with time and an
understanding of the process.

> About Reviewed-by, if you have say a 10 patches set, is one-by-one
> interactive rebase the only way to add the tag to all the patches?
> I'm not too attached to the one click pull request merging from the
> web UI... pulling and pushing on the command line is not too
> complicated. Though if you have to modify patches one by one it
> starts to get annoying...

Either the contributor or a maintainer may aggregate the tags before
pushing.  The reviewer or tester need not, but may.

The method I like best is to commit the patch on a local branch that
is specific to the patch, and when a new tag is seen in e-mail amend
the commit.

For a multiple patch set, I would branch again from the point before
the patch, apply the patch, then commit again.

-- 
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] Reviews experiment

[James Cameron]

On Wed, Apr 03, 2013 at 09:47:14PM +0200, Daniel Narvaez wrote:
> 2. Reviewers will get email notifications when new patches are
> posted. Please use the web interface to comment on the changes and
> request fixes.

Are you saying I won't be able to read the patch in e-mail, and won't
be able reply to it with Reviewed-by, Acked-by or Tested-by?  I often
read my mail when I have no web interface.

I don't understand how making reviews harder would improve the
probability of review.

-- 
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] Acked-by vs Reviewed-by

[James Cameron]

On Wed, Apr 03, 2013 at 10:07:07PM +0200, Daniel Narvaez wrote:
> it seems that most of our patches should have a Reviewed-by tag, on the
> contrary I see Acked-by used most of the time (at the top of the
> sugar-toolkit-gtk3 log at least).
> 
> Am I missing something?

I agree with others; for Glucose since I am not maintainer I would add
Reviewed-by, but for Pippy since I am maintainer I would add Acked-by.

(If I add Acked-by to a patch, I might also push it, depending on
whether the contributor is known to be able to push, and whether more
work is happening right at the moment.)

-- 
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] Reviews experiment

[Daniel Narvaez]

On 3 April 2013 23:16, Manuel Quiñones  wrote:

> 2013/4/3 Daniel Narvaez :
> > Cool!
> >
> > I suppose you are going to want that on the 0.98 branch too. I'm not sure
> > what we should in those cases exactly... I mean merge it in github or in
> > gitorious directly? No strong feeling here.
>
> I guess we can pull from github master being in gitorious master, then
> git cherry-pick from master being in the sucrose-0.98 branch.
>

That's OK with me. Not sure about 0.98 only patches, but hopefully there
won't be many of those :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Acked-by vs Reviewed-by

[Manuel Quiñones]

2013/4/3 Daniel Narvaez :
> Ok I see how you can read
> https://www.kernel.org/doc/Documentation/SubmittingPatches that way.
>
> Though, man, the whole document feels so unnecessarily complicated and
> unclear if applied to Sugar. If we keep using these tags I think we should
> write a simpler explanation which applies to our project.

+1 to revisit the need of this.

--
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Reviews experiment

[Manuel Quiñones]

2013/4/3 Daniel Narvaez :
> Cool!
>
> I suppose you are going to want that on the 0.98 branch too. I'm not sure
> what we should in those cases exactly... I mean merge it in github or in
> gitorious directly? No strong feeling here.

I guess we can pull from github master being in gitorious master, then
git cherry-pick from master being in the sucrose-0.98 branch.

--
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Reviews experiment

[Daniel Narvaez]

On 3 April 2013 22:12, Gonzalo Odiard  wrote:

> What is the plan, master in github and 0.98 branch in gitorious?


Yeah, brought that up in another email with Manuel. That would be my guess
but it's really up to you guys I think, whatever you are most comfortable
with.


>
> Where is pointing sugar-build now?
>
>
I will merge back master regularly to gitorious, we should only change the
official repo once the experiment is over. Though I think it make sense to
point sugar-build to github repos. I'll do that tomorrow unless someone
disagrees.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Acked-by vs Reviewed-by

[Daniel Narvaez]

Ok I see how you can read
https://www.kernel.org/doc/Documentation/SubmittingPatches that way.

Though, man, the whole document feels so unnecessarily complicated and
unclear if applied to Sugar. If we keep using these tags I think we should
write a simpler explanation which applies to our project.


On 3 April 2013 22:11, Gonzalo Odiard  wrote:

> I think only the maintainer can Ack (and imply a review)
> and anybody else can add a Reviewed-by
>
> Gonzalo
>
> On Wed, Apr 3, 2013 at 5:07 PM, Daniel Narvaez wrote:
>
>> Hi,
>>
>> it seems that most of our patches should have a Reviewed-by tag, on the
>> contrary I see Acked-by used most of the time (at the top of the
>> sugar-toolkit-gtk3 log at least).
>>
>> Am I missing something?
>>
>> --
>> 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] Reviews experiment

[Gonzalo Odiard]

On Wed, Apr 3, 2013 at 5:10 PM, Daniel Narvaez  wrote:

> Cool!
>
> I suppose you are going to want that on the 0.98 branch too. I'm not sure
> what we should in those cases exactly... I mean merge it in github or in
> gitorious directly? No strong feeling here.
>
>
What is the plan, master in github and 0.98 branch in gitorious?
Where is pointing sugar-build now?

Gonzalo



>
> On 3 April 2013 22:04, Manuel Quiñones  wrote:
>
>> 2013/4/3 Daniel Narvaez :
>> > Hello,
>> >
>> > we now have a list of reviewers but we still need to figure out a good
>> > review workflow.
>> >
>> > I and Walter have been playing with github pull requests in the past few
>> > days. Let's try to extend the experiment to everyone and test if it
>> really
>> > works well for us. Essentially this means a couple of things
>> >
>> > 1. Patch contributors should submit their code using pull requests. I
>> setup
>> > forks of the Glucose repositories here (I will take care of syncing
>> back to
>> > gitorious).
>> >
>> > https://github.com/sugarlabs
>> >
>> > If you are not familiar with it, see the official github documentation
>> >
>> > https://help.github.com/articles/using-pull-requests
>> >
>> > 2. Reviewers will get email notifications when new patches are posted.
>> > Please use the web interface to comment on the changes and request
>> fixes.
>> > When you are happy with the patch, feel free to merge it. Some info on
>> how
>> > to do it
>> >
>> > https://help.github.com/articles/merging-a-pull-request
>> >
>> > There has been some discussion on the list about the details of the
>> > workflow, but really I would like everyone to try things out before
>> > documenting the process more precisely. Similarly I'm planning to write
>> a
>> > checklist reviewers should follow but I'd like that to emerge from the
>> > experiment.
>> >
>> > Let's post any question, doubt or complaint to the list, so that
>> everyone
>> > can participate in the discussion.
>>
>> Well done!  I have a patch in the workings for:
>> http://bugs.sugarlabs.org/ticket/3819
>>
>> It is a bugfix that brings back the drag and drop to the clipboard
>> inside the frame.  Will do the pull request when I finish.
>>
>> .. manuq ..
>>
>
>
>
> --
> Daniel Narvaez
>
> ___
> 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] Acked-by vs Reviewed-by

[Gonzalo Odiard]

I think only the maintainer can Ack (and imply a review)
and anybody else can add a Reviewed-by

Gonzalo

On Wed, Apr 3, 2013 at 5:07 PM, Daniel Narvaez  wrote:

> Hi,
>
> it seems that most of our patches should have a Reviewed-by tag, on the
> contrary I see Acked-by used most of the time (at the top of the
> sugar-toolkit-gtk3 log at least).
>
> Am I missing something?
>
> --
> Daniel Narvaez
>
> ___
> 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] Reviews experiment

[Daniel Narvaez]

Cool!

I suppose you are going to want that on the 0.98 branch too. I'm not sure
what we should in those cases exactly... I mean merge it in github or in
gitorious directly? No strong feeling here.


On 3 April 2013 22:04, Manuel Quiñones  wrote:

> 2013/4/3 Daniel Narvaez :
> > Hello,
> >
> > we now have a list of reviewers but we still need to figure out a good
> > review workflow.
> >
> > I and Walter have been playing with github pull requests in the past few
> > days. Let's try to extend the experiment to everyone and test if it
> really
> > works well for us. Essentially this means a couple of things
> >
> > 1. Patch contributors should submit their code using pull requests. I
> setup
> > forks of the Glucose repositories here (I will take care of syncing back
> to
> > gitorious).
> >
> > https://github.com/sugarlabs
> >
> > If you are not familiar with it, see the official github documentation
> >
> > https://help.github.com/articles/using-pull-requests
> >
> > 2. Reviewers will get email notifications when new patches are posted.
> > Please use the web interface to comment on the changes and request fixes.
> > When you are happy with the patch, feel free to merge it. Some info on
> how
> > to do it
> >
> > https://help.github.com/articles/merging-a-pull-request
> >
> > There has been some discussion on the list about the details of the
> > workflow, but really I would like everyone to try things out before
> > documenting the process more precisely. Similarly I'm planning to write a
> > checklist reviewers should follow but I'd like that to emerge from the
> > experiment.
> >
> > Let's post any question, doubt or complaint to the list, so that everyone
> > can participate in the discussion.
>
> Well done!  I have a patch in the workings for:
> http://bugs.sugarlabs.org/ticket/3819
>
> It is a bugfix that brings back the drag and drop to the clipboard
> inside the frame.  Will do the pull request when I finish.
>
> .. manuq ..
>



-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Acked-by vs Reviewed-by

[Daniel Narvaez]

Hi,

it seems that most of our patches should have a Reviewed-by tag, on the
contrary I see Acked-by used most of the time (at the top of the
sugar-toolkit-gtk3 log at least).

Am I missing something?

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Reviews experiment

[Manuel Quiñones]

2013/4/3 Daniel Narvaez :
> Hello,
>
> we now have a list of reviewers but we still need to figure out a good
> review workflow.
>
> I and Walter have been playing with github pull requests in the past few
> days. Let's try to extend the experiment to everyone and test if it really
> works well for us. Essentially this means a couple of things
>
> 1. Patch contributors should submit their code using pull requests. I setup
> forks of the Glucose repositories here (I will take care of syncing back to
> gitorious).
>
> https://github.com/sugarlabs
>
> If you are not familiar with it, see the official github documentation
>
> https://help.github.com/articles/using-pull-requests
>
> 2. Reviewers will get email notifications when new patches are posted.
> Please use the web interface to comment on the changes and request fixes.
> When you are happy with the patch, feel free to merge it. Some info on how
> to do it
>
> https://help.github.com/articles/merging-a-pull-request
>
> There has been some discussion on the list about the details of the
> workflow, but really I would like everyone to try things out before
> documenting the process more precisely. Similarly I'm planning to write a
> checklist reviewers should follow but I'd like that to emerge from the
> experiment.
>
> Let's post any question, doubt or complaint to the list, so that everyone
> can participate in the discussion.

Well done!  I have a patch in the workings for:
http://bugs.sugarlabs.org/ticket/3819

It is a bugfix that brings back the drag and drop to the clipboard
inside the frame.  Will do the pull request when I finish.

.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Reviews experiment

[Daniel Narvaez]

Hello,

we now have a list of reviewers but we still need to figure out a good
review workflow.

I and Walter have been playing with github pull requests in the past few
days. Let's try to extend the experiment to everyone and test if it really
works well for us. Essentially this means a couple of things

1. Patch contributors should submit their code using pull requests. I setup
forks of the Glucose repositories here (I will take care of syncing back to
gitorious).

https://github.com/sugarlabs

If you are not familiar with it, see the official github documentation

https://help.github.com/articles/using-pull-requests

2. Reviewers will get email notifications when new patches are posted.
Please use the web interface to comment on the changes and request fixes.
When you are happy with the patch, feel free to merge it. Some info on how
to do it

https://help.github.com/articles/merging-a-pull-request

There has been some discussion on the list about the details of the
workflow, but really I would like everyone to try things out before
documenting the process more precisely. Similarly I'm planning to write a
checklist reviewers should follow but I'd like that to emerge from the
experiment.

Let's post any question, doubt or complaint to the list, so that everyone
can participate in the discussion.

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] f19 alpha TC3 soas and sugar-desktop fail to finish booting into f3 (home) screen

[Manuel Quiñones]

2013/4/3 Thomas Gilliard :
> Soas and sugar-desktop seem to be  unusable at the moment:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=947538

Same happens in my netbook.  It stalls in the home screen.  If I
switch to a text console and use the top command, I see a python
process taking all the CPU.  This process is owned by liveuser user.

If I can be of any help testing, bring me instructions.

>
> Tom Gilliard
> satellit
> ___
> 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] [IAEP] FW: Sugar 0.100 status report - April 2

[Manuel Quiñones]

The feature page doesn't explicitly state, but I remember it allows
batch removal.

http://wiki.sugarlabs.org/go/Features/Multi_selection

2013/4/3 Daniel Narvaez :
> Adding devel and Ajay.
>
>
> On 3 April 2013 19:26, Caryl Bigenho  wrote:
>>
>> I guess this is where this should go? Clue me in if it should be posted
>> elsewhere.
>>
>> Caryl
>>
>> 
>> Date: Wed, 3 Apr 2013 18:05:36 +0200
>> Subject: Re: [IAEP] Sugar 0.100 status report - April 2
>> From: dwnarv...@gmail.com
>> To: cbige...@hotmail.com
>>
>>
>> Hi Caryl,
>>
>> could you post this on the list?. I don't know the answer to your
>> questions, but the patches author will know for sure...
>>
>>
>> On 3 April 2013 02:04, Caryl Bigenho  wrote:
>>
>> Hi...
>>
>> Looks like great stuff! Adapting Sugar to run on Android opens lots of
>> possibilities. My programming days ended long ago with Pascal, but I might
>> be able to offer some suggestions as a Sugar user... here's one to start...
>>
>> For the multiple selection of items in the journal... will this also allow
>> multiple deletion of entries? That would be a handy feature I have often
>> wished were available. Also, do the selected items have to be consecutive?
>> Could some be skipped over (either initially or by allowing a deselect of
>> individual items that aren't wanted on the list).
>>
>> Caryl
>>
>>
>>
>> 
>> Date: Wed, 3 Apr 2013 00:37:08 +0200
>> From: dwnarv...@gmail.com
>> To: sugar-devel@lists.sugarlabs.org
>> CC: i...@lists.sugarlabs.org
>> Subject: [IAEP] Sugar 0.100 status report - April 2
>>
>>
>> Hello,
>>
>> I will try to send out regular reports about the progress of the 0.100
>> release, weekly, bi-weekly or monthly depending on how much is happening.
>>
>> 1. A bit late, but we finally have a schedule for the release.We are not
>> going to have a feature acceptance deadline this time. We decided to have
>> that discussion early, to try and narrow the focus of the release.
>>
>> http://wiki.sugarlabs.org/go/0.100/Roadmap
>>
>> 2. In parallel some developers will keep to refine the 0.98 series. Help
>> is welcome on that effort. While perhaps not as exciting as new features,
>> bug fixing and polish is essential to good software.
>>
>> 3. The main goal of the 0.100 release will be to the develop an HTML5
>> based toolkit for activities. This will facilitate running Sugar activities
>> on other platforms, like Android. In addition we are planning to land
>> several other features which has seen development in the past few months
>>
>> Multiple selection in the Journal
>> http://wiki.sugarlabs.org/go/Features/Multi_selection
>>
>> Enhanced support for 3G modems
>> http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support
>>
>> Background customization
>> http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view
>>
>> Multiple home views
>> http://wiki.sugarlabs.org/go/Features/Multiple_home_views
>>
>> Integration with web services
>> http://wiki.sugarlabs.org/go/Features/Web_services
>>
>> Journal comments box
>> http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view
>>
>> Icon customization
>> http://wiki.sugarlabs.org/go/Features/Icon_Change
>>
>> 4. The project has always had a bit of an issue with submitted code being
>> timely reviewed. The situation got worse in the last few months. This is a
>> major blocker for contributions and we are trying to improve. Simon and
>> Manuel, which currently maintains all the Glucose modules alone, are putting
>> together a list of "reviewers" to help them out with the task. We are also
>> trying to find review tools which will allow the process to be both
>> trackable and visible to everyone (and hopefully a bit more pleasant too!).
>> We have so far mostly experimented with a workflow based on github pull
>> requests.
>>
>> 5. Walter Bender landed several patches to add a comment box to journal
>> entries. It will be populated both by the Portfolio activity and by the web
>> services integration which is being worked on. The obligatory screenshot
>>
>> http://wiki.sugarlabs.org/images/4/4a/FB-comments.png
>>
>> 6. All in all I think we made great progress planning the next release.
>> But we will need everyone help to execute and make it a really good one.
>>
>> --
>> Daniel Narvaez
>>
>> ___ IAEP -- It's An Education
>> Project (not a laptop project!) i...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>>
>>
>>
>>
>> --
>> Daniel Narvaez
>>
>> ___
>> IAEP -- It's An Education Project (not a laptop project!)
>> i...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>
>
>
>
> --
> Daniel Narvaez
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
.. manuq ..

Re: [Sugar-devel] JournalShare status

[Gonzalo Odiard]

> Thanks Gonzalo for the write-up!
>
> The first thing that caught my eye was the way to define which items
> should be shared. I wouldn't use the favorite metaphor for that. That works
> for the Portfolio activity well, but here it is the wrong one, imho.
>
> It should be explicit which items I want to share, using the Objectchooser
> looks like the right approach. You might actually as well to share an
> object from a usb key or an external sd-card, here the metaphor of a
> favorite item works even less.
>
>
I agree. Anyway, share the favorites items can be a option (if explicitly
selected by the user) .



> Another thing that is important is the notion of other members of the
> session. I presume the communication should happen in all directions (e.g.
> a teacher and five students each member of the session can share items with
> the other one), therefore it is important to know who is in the session and
> who has offered what.
>
>
True, we need show the objects ownership.


> Actually, we should think as well whether it should be a push or a pull
> model. The current file transfers (with friended buddies) are a push model
> where the receiver can accept or decline. I think here it is more of a
> bulletin board (some ideas for wording and similar you might find here [1])
> where people post items they want to be shared with the group, so a pull
> model makes sense here, imho.
>
>
I like use a push model because is more transparent to the user (like in
Record or Browse collaboration),
but these activities have it partially implemented, if you remove media
from one xo, is not removed in other
xos, the same happen if you change the title from one photo, is not changed
in the other xos.
I don't know if is in this way by design or because is pending.

One alternative is notify to the user when changes were pushed to the main
shared instance. Then, the user can reload
and get the view updated.

Thanks by the review & ideas.

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] FW: Sugar 0.100 status report - April 2

[Daniel Narvaez]

Adding devel and Ajay.


On 3 April 2013 19:26, Caryl Bigenho  wrote:

> I guess this is where this should go? Clue me in if it should be posted
> elsewhere.
>
> Caryl
>
> --
> Date: Wed, 3 Apr 2013 18:05:36 +0200
> Subject: Re: [IAEP] Sugar 0.100 status report - April 2
> From: dwnarv...@gmail.com
> To: cbige...@hotmail.com
>
>
> Hi Caryl,
>
> could you post this on the list?. I don't know the answer to your
> questions, but the patches author will know for sure...
>
>
> On 3 April 2013 02:04, Caryl Bigenho  wrote:
>
> Hi...
>
> Looks like great stuff! Adapting Sugar to run on Android opens lots of
> possibilities. My programming days ended long ago with Pascal, but I might
> be able to offer some suggestions as a Sugar user... here's one to start...
>
> For the multiple selection of items in the journal... will this also allow
> multiple deletion of entries? That would be a handy feature I have often
> wished were available. Also, do the selected items have to be consecutive?
> Could some be skipped over (either initially or by allowing a deselect of
> individual items that aren't wanted on the list).
>
> Caryl
>
>
>
> --
> Date: Wed, 3 Apr 2013 00:37:08 +0200
> From: dwnarv...@gmail.com
> To: sugar-devel@lists.sugarlabs.org
> CC: i...@lists.sugarlabs.org
> Subject: [IAEP] Sugar 0.100 status report - April 2
>
>
> Hello,
>
> I will try to send out regular reports about the progress of the 0.100
> release, weekly, bi-weekly or monthly depending on how much is happening.
>
> 1. A bit late, but we finally have a schedule for the release.We are not
> going to have a feature acceptance deadline this time. We decided to have
> that discussion early, to try and narrow the focus of the release.
>
> http://wiki.sugarlabs.org/go/0.100/Roadmap
>
> 2. In parallel some developers will keep to refine the 0.98 series. Help
> is welcome on that effort. While perhaps not as exciting as new features,
> bug fixing and polish is essential to good software.
>
> 3. The main goal of the 0.100 release will be to the develop an HTML5
> based toolkit for activities. This will facilitate running Sugar activities
> on other platforms, like Android. In addition we are planning to land
> several other features which has seen development in the past few months
>
> Multiple selection in the Journal
> http://wiki.sugarlabs.org/go/Features/Multi_selection
>
> Enhanced support for 3G modems
> http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support
>
> Background customization
> http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view
>
> Multiple home views
> http://wiki.sugarlabs.org/go/Features/Multiple_home_views
>
> Integration with web services
> http://wiki.sugarlabs.org/go/Features/Web_services
>
> Journal comments box
> http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view
>
> Icon customization
> http://wiki.sugarlabs.org/go/Features/Icon_Change
>
> 4. The project has always had a bit of an issue with submitted code being
> timely reviewed. The situation got worse in the last few months. This is a
> major blocker for contributions and we are trying to improve. Simon and
> Manuel, which currently maintains all the Glucose modules alone, are
> putting together a list of "reviewers" to help them out with the task. We
> are also trying to find review tools which will allow the process to be
> both trackable and visible to everyone (and hopefully a bit more pleasant
> too!). We have so far mostly experimented with a workflow based on github
> pull requests.
>
> 5. Walter Bender landed several patches to add a comment box to journal
> entries. It will be populated both by the Portfolio activity and by the web
> services integration which is being worked on. The obligatory screenshot
>
> http://wiki.sugarlabs.org/images/4/4a/FB-comments.png
>
> 6. All in all I think we made great progress planning the next release.
> But we will need everyone help to execute and make it a really good one.
>
> --
> Daniel Narvaez
>
> ___ IAEP -- It's An Education
> Project (not a laptop project!) i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
>
>
> --
> Daniel Narvaez
>
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Glucose code reviewers

[Daniel Narvaez]

Hello,

as discussed, we have put together a list of reviewers for the Glucose
modules. They role will be to help out maintainers reviewing, approving and
landing patches.

Here they are!

Walter Bender 
Daniel Narvaez 
Daniel Drake 
Gonzalo Odiard 
James Cameron 
Ajay Garg 

Of course everyone else is still welcome and encouraged to do code reviews.
We hope the list will grow!

We are still figuring out workflow and coordination, I will follow up on
that shortly.

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Usage of Signed-off-by / Acked-by - Re: Recent movement on Sugar master repository

[Daniel Narvaez]

Perhaps you can explain exactly what Signed-off-by adds compared to the
author field in tnormal cases? I know it's not much work, but it adds one
more thing we need to request to patch submitters. I tend to think the
simpler is the process the more patches we will get :) Or at least I
personally get really annoyed by bureaucracy when submitting code.

About Reviewed-by, if you have say a 10 patches set, is one-by-one
interactive rebase the only way to add the tag to all the patches? I'm not
too attached to the one click pull request merging from the web UI...
pulling and pushing on the command line is not too complicated. Though if
you have to modify patches one by one it starts to get annoying...



On 3 April 2013 15:00, Gonzalo Odiard  wrote:

> I think we should keep using the Signed-off-by, Acked-by, Reviewed-by
> signatures, because do not add too much work,
> make clear the responsibilities, and recognize important work done
> as the review, needed by the project.
>
> Gonzalo
>
>
> On Tue, Apr 2, 2013 at 2:41 PM, Manuel Quiñones  wrote:
>
>> As we are revisiting all the review process, can we revisit the usage
>> of signing the patches?  What are they useful for?
>>
>> 2013/4/2 Daniel Narvaez :
>> > So I'm not sure these are worth the overhead. Especially for  signing it
>> > doesn't seem to be very useful for us, if not in some special cases,
>> and it
>> > adds one more thing we need to require from contributors... I'd rather
>> bug
>> > them about improving the code then about using a tag of dubious utility.
>> >
>> > Just my feeling really, I'm happy to keep using the tags if we think
>> they
>> > are necessary. Just trying to streamline things a bit if possible.
>>
>> Yes, I agree with you Daniel.  I think we need the point of view of
>> other devs, specially from those who are in the project prior than us.
>>
>> >
>> > On 2 April 2013 19:25, Manuel Quiñones  wrote:
>> >>
>> >> Hi Daniel,
>> >>
>> >> 2013/4/2 Daniel Narvaez :
>> >> > Hey,
>> >> >
>> >> > sorry, I forgot about those. Though I think it's worth to think if we
>> >> > really
>> >> > need them while we are reworking reviews a bit.
>> >> >
>> >> > When is signed-off-by useful in sugar?
>> >>
>> >> I think we just have been following other projects like the linux
>> >> kernel.  In many projects this means "I certify that my code is
>> >> compatible with the license of this project".  For me, it is useful
>> >> only if the commiter is another user, to track the real author.
>> >>
>> >> http://wiki.sugarlabs.org/go/Development_Team/Code_Review
>> >>
>> >> > How is reviewed-by applied? Is it the reviewer which rebase and add
>> them
>> >> > before pushing?
>> >>
>> >> Yes we have been amending the patches before pushing, all manual work.
>> >>  For me, the Acked-by signing has been useful to track who reviewed
>> >> what.  But maybe not a big deal?
>> >>
>> >> So there are projects that do signing, and projects that don't.  I
>> >> searched quickly for a way to add Acked-by when github merges a pull
>> >> request, but haven't found anything.
>> >>
>> >> > On 2 April 2013 18:30, Manuel Quiñones  wrote:
>> >> >>
>> >> >> Hi devs,
>> >> >>
>> >> >> I've seen some movement in current master.  I suppose all this was
>> >> >> reviewed, but what I wonder is if we are sticking to the
>> signed-off-by
>> >> >> / acked-by signing.
>> >> >>
>> >> >> The commits in question are:
>> >> >>
>> >> >> commit f423ec21b4bf0d953a470a383cc801b61a087e98
>> >> >> Author: Walter Bender 
>> >> >> Date:   Sat Mar 30 16:06:00 2013 -0400
>> >> >>
>> >> >> Add comment box to expanded entry
>> >> >>
>> >> >> commit 541af0166030a5f3b7b52bdc23d416dbf688b5e9
>> >> >> Author: Walter Bender 
>> >> >> Date:   Sat Mar 30 10:45:22 2013 -0400
>> >> >>
>> >> >> Add CommentView widget to expanded entry
>> >> >>
>> >> >> commit 248a758875e5a02a53ae57980f4fe2f3bb0bb91e
>> >> >> Author: Walter Bender 
>> >> >> Date:   Thu Mar 28 15:26:17 2013 -0400
>> >> >>
>> >> >> Make a separate method for _write_entry so method can be reused
>> >> >>
>> >> >> commit 1af4b5ec7f03ed43da1616df946fe936e8577e91
>> >> >> Author: Walter Bender 
>> >> >> Date:   Thu Mar 28 15:25:41 2013 -0400
>> >> >>
>> >> >> Pass a widget to _create_scrollable so method can be reused
>> >> >>
>> >> >>
>> >> >> --
>> >> >> .. manuq ..
>> >> >> ___
>> >> >> Sugar-devel mailing list
>> >> >> Sugar-devel@lists.sugarlabs.org
>> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Daniel Narvaez
>> >>
>> >>
>> >>
>> >> --
>> >> .. manuq ..
>> >
>> >
>> >
>> >
>> > --
>> > Daniel Narvaez
>>
>>
>>
>> --
>> .. manuq ..
>> ___
>> 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
htt

Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)

[Daniel Narvaez]

On 3 April 2013 14:27, Gonzalo Odiard  wrote:

> The problem with changing trac is lost our bugs history.
> In fact, changing trac was discussed before, but the problem is how move
> all the information
> we have right now. It's a pain need to check for bugs in dev.laptop.organd in
> bugs.sugarlabs.org. Add one more and will be worst :(
> If we can export the bug database, should be better, but I don't know if
> anybody have time
> to look at that.
>
>
It's probably not too difficult, we don't have that many bugs and there are
trac->github scripts around. Though everyone is really busy around here :)
The good thing is that the step is optional, we can do it if/when we fill
it's worth the effort.

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar networking

[Gonzalo Odiard]

Fixing bugs is always welcomed.
Networking/collaboration is not so easy, then is a area where help
is really needed.
Go ahead, and maintain communication with sugar-devel

Gonzalo

On Wed, Apr 3, 2013 at 11:25 AM, William Orr  wrote:

> Hello,
>
> I emailed this list some time ago about fixing Sugar bugs for my H/FOSS
> class at RIT. Matt and I found some bugs on our own related to the
> generated network neighborhood and sharing activities over the network.
>
> Is it worth our time and valuable to the community to start squashing
> these bugs? Or is there something more valuable we could be doing? We
> noticed there's a lot of talk about migrating activities over to HTML5, but
> we're concerned that the work we could do on that would not fit into the
> timeline of our class (we need some kind of deliverable in a little over a
> month).
>
> Any help and guidance would be appreciated!
> __**_
> 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] f19 alpha TC3 soas and sugar-desktop fail to finish booting into f3 (home) screen

[Peter Robinson]

It depends, it's fine on my netbook, I have issues with virtmanager to do
with keyboard post firstboot screen.


On Wed, Apr 3, 2013 at 3:15 PM, Thomas Gilliard
wrote:

> Soas and sugar-desktop seem to be  unusable at the moment:
>
> https://bugzilla.redhat.com/**show_bug.cgi?id=947538
>
> Tom Gilliard
> satellit
> __**_
> 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

[Sugar-devel] Sugar networking

[William Orr]

Hello,

I emailed this list some time ago about fixing Sugar bugs for my H/FOSS 
class at RIT. Matt and I found some bugs on our own related to the 
generated network neighborhood and sharing activities over the network.


Is it worth our time and valuable to the community to start squashing 
these bugs? Or is there something more valuable we could be doing? We 
noticed there's a lot of talk about migrating activities over to HTML5, 
but we're concerned that the work we could do on that would not fit into 
the timeline of our class (we need some kind of deliverable in a little 
over a month).


Any help and guidance would be appreciated!
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ASLO] Release Music Keyboard-6

[Gonzalo Odiard]

On Thu, Mar 28, 2013 at 3:38 PM, Caryl Bigenho  wrote:

> Hi Guys,
>
> Yes, I do have a AB in Music and an MA in Music Ed. I need to take a look
> at the keyboard to see how Gonzalo has laid it out.  But there are a few
> factors to think about.
>
> There are 2 systems using Do-Re-Mi in solfege, the "fixed Do" and the
> "movable Do." With the fixed Do method, Do is always the note C, Sol is
> always G and so forth. This method is used in many places. The "movable Do"
> method is where Do is the first note of the scale, so if a song is in the
> key of G (for example), Do will be G, Sol will be D and so forth.
>
> Supposedly these methods are used in different locales. In the US we use
> the movable Do. Latin America supposedly uses the fixed Do, however, when I
> asked the teachers in Uruguay (at Rosamel's school) whether they were using
> the fixed Do or the movable Do, they indicated they used the movable Do.
>
> More importantly, Tam Tam uses the movable Do! This is evident when you
> switch to different "instruments" and test them with an electric tuner
> (which I have done). You will see that what would be the C key on most
> keyboard instruments may be something entirely different. So, it seems
> logical to use the movable Do with the XO. Maybe that is why they use it in
> Uruguay with their XOs.
>
>
At least one teacher complained about this issue with TamTam. He said the
kids can't play a song with multiple instruments due to different tuning.


> Now, for the syllables... Do, Re, Me, Fa, Sol, La, Ti, Do are standard for
> the major scale in the US and many other countries. Some countries (Uruguay
> for example) use Si instead of Ti for the 7th tone. The Kodaly method (a
> method of teaching music to children) also uses the movable Do.
>
>
At least in Argentina, "Si" is used instead of "Ti"



> I suggest you might want to look over the little FLOSS manual I have put
> together for Tam Tam if you want to learn a little bit more about this. I
> still haven't done the final edits, but it is quite usable the way it is.
>
> http://booki.flossmanuals.net/fun-with-tam-tam/_full/
>
>
Great.


> Now... I just had what one of my Ed Profs called a "BGO" (Blazing Glimpse
> of the Obvious). If the XO-4 is going to have an on-screen keyboard there
> is no reason why there couldn't be alternate keyboards available. One to
> consider using would be for the pentatonic (5 tone) scale used by Orff
> Schulwerke. (http://en.wikipedia.org/wiki/Orff_Schulwerk).
>
> To use an Orff-like method with the XOs someone (probably me, I guess)
> would need to take a deeper look into its workings and come up with some
> suitable lessons that would be easy for teachers to use. We probably
> wouldn't want to call it Orff Schulwerke as that name is probably
> protected, but some of the same techniques could be used, which I think you
> will see fit in nicely with PBL, Cooperative Learning, and Constructionism.
>
> I know this is way more information than you wanted, but it is food for
> thought!
>

This is more than I can do right now. But if anybody is interested, is
welcomed.

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] f19 alpha TC3 soas and sugar-desktop fail to finish booting into f3 (home) screen

[Thomas Gilliard]

Soas and sugar-desktop seem to be  unusable at the moment:

https://bugzilla.redhat.com/show_bug.cgi?id=947538

Tom Gilliard
satellit
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Github review workflow

[Gonzalo Odiard]

The pull request in github sent a mail to the maintainer?
In gitorious the maintainer does not receive a mail,
I think that was part of the problem.

Gonzalo


On Tue, Apr 2, 2013 at 3:13 PM, Walter Bender wrote:

> On Tue, Apr 2, 2013 at 1:47 PM, Manuel Quiñones  wrote:
> > 2013/4/2 Daniel Narvaez :
> >> On 2 April 2013 16:43, Manuel Quiñones  wrote:
> >>>
> >>> > 7 Push the changes to another remote branch
> >>>
> >>> Is there a need for a new branch for each pull request?  Pushing again
> >>> to the topic1 will automatically update the pull request in github.
> >>
> >>
> >> The problem is when rebasing (i.e. making changes to any of the already
> >> reviewed commits), which is a very very frequent case... You either
> need to
> >> use another branch or to git push -f, which I'm not too comfortable
> with,
> >> I'm worried I would it use it accidentally somewhere else if I got used
> to
> >> it...
> >>
> >> Do you know how people generally deals with that case?
> >
> > No, it's worth taking a look at other open projects.
> >
> >> The only other option I can think of is to fix the reviewer complaints
> in
> >> another commit, which I don't like much because it makes a mess of the
> >> history.
> >
> > Yes, you are right.  Fixing by adding more commits is a mess.  So
> > taking into account that, branching and opening another pull requests
> > as you originally proposed makes sense.
>
> I was a bit skeptical at first, but it has not been too painful.
>
> -walter
> >
> >>>
> >>> I think we should have shortcuts too, to not block too much.  For a
> >>> simple patch for example, the maintainer could be able to add minor
> >>> tweaks to the pull request and do a manual merge, instead of asking
> >>> another reviewing loop.
> >>
> >>
> >> Yup.
> >
> >
> >
> > --
> > .. manuq ..
> > ___
> > 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
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Tag for Sugar 0.100 in ASLO

[Manuel Quiñones]

Hi ASLO maintainers,

sooner or later we'll need the 0.100 tag.  I would like to have it
soon to upload latest Browse, so it can be grabbed in olpc builds.

Thanks in advance,

--
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Usage of Signed-off-by / Acked-by - Re: Recent movement on Sugar master repository

[Gonzalo Odiard]

I think we should keep using the Signed-off-by, Acked-by, Reviewed-by
signatures, because do not add too much work,
make clear the responsibilities, and recognize important work done
as the review, needed by the project.

Gonzalo


On Tue, Apr 2, 2013 at 2:41 PM, Manuel Quiñones  wrote:

> As we are revisiting all the review process, can we revisit the usage
> of signing the patches?  What are they useful for?
>
> 2013/4/2 Daniel Narvaez :
> > So I'm not sure these are worth the overhead. Especially for  signing it
> > doesn't seem to be very useful for us, if not in some special cases, and
> it
> > adds one more thing we need to require from contributors... I'd rather
> bug
> > them about improving the code then about using a tag of dubious utility.
> >
> > Just my feeling really, I'm happy to keep using the tags if we think they
> > are necessary. Just trying to streamline things a bit if possible.
>
> Yes, I agree with you Daniel.  I think we need the point of view of
> other devs, specially from those who are in the project prior than us.
>
> >
> > On 2 April 2013 19:25, Manuel Quiñones  wrote:
> >>
> >> Hi Daniel,
> >>
> >> 2013/4/2 Daniel Narvaez :
> >> > Hey,
> >> >
> >> > sorry, I forgot about those. Though I think it's worth to think if we
> >> > really
> >> > need them while we are reworking reviews a bit.
> >> >
> >> > When is signed-off-by useful in sugar?
> >>
> >> I think we just have been following other projects like the linux
> >> kernel.  In many projects this means "I certify that my code is
> >> compatible with the license of this project".  For me, it is useful
> >> only if the commiter is another user, to track the real author.
> >>
> >> http://wiki.sugarlabs.org/go/Development_Team/Code_Review
> >>
> >> > How is reviewed-by applied? Is it the reviewer which rebase and add
> them
> >> > before pushing?
> >>
> >> Yes we have been amending the patches before pushing, all manual work.
> >>  For me, the Acked-by signing has been useful to track who reviewed
> >> what.  But maybe not a big deal?
> >>
> >> So there are projects that do signing, and projects that don't.  I
> >> searched quickly for a way to add Acked-by when github merges a pull
> >> request, but haven't found anything.
> >>
> >> > On 2 April 2013 18:30, Manuel Quiñones  wrote:
> >> >>
> >> >> Hi devs,
> >> >>
> >> >> I've seen some movement in current master.  I suppose all this was
> >> >> reviewed, but what I wonder is if we are sticking to the
> signed-off-by
> >> >> / acked-by signing.
> >> >>
> >> >> The commits in question are:
> >> >>
> >> >> commit f423ec21b4bf0d953a470a383cc801b61a087e98
> >> >> Author: Walter Bender 
> >> >> Date:   Sat Mar 30 16:06:00 2013 -0400
> >> >>
> >> >> Add comment box to expanded entry
> >> >>
> >> >> commit 541af0166030a5f3b7b52bdc23d416dbf688b5e9
> >> >> Author: Walter Bender 
> >> >> Date:   Sat Mar 30 10:45:22 2013 -0400
> >> >>
> >> >> Add CommentView widget to expanded entry
> >> >>
> >> >> commit 248a758875e5a02a53ae57980f4fe2f3bb0bb91e
> >> >> Author: Walter Bender 
> >> >> Date:   Thu Mar 28 15:26:17 2013 -0400
> >> >>
> >> >> Make a separate method for _write_entry so method can be reused
> >> >>
> >> >> commit 1af4b5ec7f03ed43da1616df946fe936e8577e91
> >> >> Author: Walter Bender 
> >> >> Date:   Thu Mar 28 15:25:41 2013 -0400
> >> >>
> >> >> Pass a widget to _create_scrollable so method can be reused
> >> >>
> >> >>
> >> >> --
> >> >> .. manuq ..
> >> >> ___
> >> >> Sugar-devel mailing list
> >> >> Sugar-devel@lists.sugarlabs.org
> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Daniel Narvaez
> >>
> >>
> >>
> >> --
> >> .. manuq ..
> >
> >
> >
> >
> > --
> > Daniel Narvaez
>
>
>
> --
> .. 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] [ASLO] Release Image Viewer-22

[Gonzalo Odiard]

Yes, confusing...
The 20s was the gtk2 branch and the 50s was the gtk3 branch,
no sure about wath is this new version.

Gonzalo

On Thu, Mar 28, 2013 at 6:02 AM, Peter Robinson wrote:

> I think we have some confusion with the versions of this.
>
> http://download.sugarlabs.org/sources/sucrose/fructose/ImageViewer/
>
> Looking here I see recent releases in their 20s and in their 50s,
> which one is which?
>
> Peter
>
> On Tue, Mar 26, 2013 at 6:07 AM, Sugar Labs Activities
>  wrote:
> > Activity Homepage:
> > http://activities.sugarlabs.org/addon/4032
> >
> > Sugar Platform:
> > 0.86 - 0.98
> >
> > Download Now:
> > http://activities.sugarlabs.org/downloads/file/28533/image_viewer-22.xo
> >
> > Release notes:
> > * Fullscreen is useless #3704
> > * Update translations
> >
> >
> > Sugar Labs Activities
> > http://activities.sugarlabs.org
> >
> > ___
> > 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
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)

[Gonzalo Odiard]

On Thu, Mar 28, 2013 at 7:01 PM, Daniel Narvaez  wrote:

> Hey Daniel!
>
> On 28 March 2013 17:53, S. Daniel Francis  wrote:
> > Just some things which come to my mind:
> >
> > * Will bugs.sugarlabs.org make sense having the github bug tracker?
>
> Integration between git and the bug tracker would be pretty awesome
> (being able to close bugs by just mentioning them in the log). Though
> it's optional really, we might migrate only when we are really really
> sure we love github :)
>
> Mostly our sysadmins seems to hate trac. If we have to move away from
> it and if we actually move code to github, then it probably make sense
> to just use the bug tracker there and enjoy the integration.
>
>
The problem with changing trac is lost our bugs history.
In fact, changing trac was discussed before, but the problem is how move
all the information
we have right now. It's a pain need to check for bugs in dev.laptop.org and
in
bugs.sugarlabs.org. Add one more and will be worst :(
If we can export the bug database, should be better, but I don't know if
anybody have time
to look at that.

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel