Re: [Sugar-devel] [sugar-html-core] Some questions regarding the bus.js API.

[Daniel Narvaez]

Good catch. By design ordering should be preserved, so this needs fixing.

On Saturday, 18 May 2013, Aneesh Dogra wrote:

> Hello list,
>
> I was just looking over some code in bus.js and I noticed that we are
> actually using a stack to prioritize and keep track of our send requests.
> The array which you name as "queue" is actually used as a stack.
>
> Here's what I think is happening:
>
> Suppose I send 3 consecutive requests:
>
> The script adds them in the "queue" variable as: [1, 2, 3]
>
> but in start we are doing:
>
>while (queue.length > 0) {
> socket.send(queue.pop());
> }
>
> so, we send the requests in order:
> 3, 2, 1
>
> Hence, the last request made later gets the first priority.
> Is this intended by design?
> --
> Thanks
> Aneesh Dogra (lionaneesh)
>


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

[Sugar-devel] [sugar-html-core] Some questions regarding the bus.js API.

[Aneesh Dogra]

Hello list,

I was just looking over some code in bus.js and I noticed that we are
actually using a stack to prioritize and keep track of our send requests.
The array which you name as "queue" is actually used as a stack.

Here's what I think is happening:

Suppose I send 3 consecutive requests:

The script adds them in the "queue" variable as: [1, 2, 3]

but in start we are doing:

   while (queue.length > 0) {
socket.send(queue.pop());
}

so, we send the requests in order:
3, 2, 1

Hence, the last request made later gets the first priority.
Is this intended by design?
-- 
Thanks
Aneesh Dogra (lionaneesh)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Paint-58

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4082

Sugar Platform:
0.96 - 0.100

Download Now:
http://activities.sugarlabs.org/downloads/file/28572/paint-58.xo

Release notes:
Remove the custom icon used to the the shapes properties button.
Solve the draw of shapes with alpha with big line width - SL #3789
Modify the toolbar to allow use with screen rotated
Updated 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] Build broken, pep8

[Daniel Narvaez]

http://buildbot.sugarlabs.org/builders/raring-amd64-quick/builds/9/steps/shell_3/logs/stdio

config.py is autogenerated, so lines can be arbitrary long.

Perhaps the simplest fix it just to use --exclude.
We could also consider switching to flake8 to run both pyflakes and pep8
and be able to skip certain lines.
Maybe it's overkill though, since we are not needing that feature other
than for this case.
 (I sort of like the asserts. To silence pyflake when necessary.)


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

Re: [Sugar-devel] 0.100 roadmap

[Manuel Quiñones]

2013/5/17 Daniel Narvaez :
> Thanks. That looks great!
>
> I wonder if it would be worth to document the desired visuals and behaviour
> while writing the code. It shouldn't take a lot of time and it could be a
> decent UI spec, useful to testers and designers too. Docco seems right for
> this kind of stuff and keeping the UI spec in the code should ensure it
> stays updated.

You read my mind!  Yes I was considering that too, it is a long
standing thing I want to do, revisit the outdated HIG.

> Thanks to Walter too for providing updates!
>
>
> On Friday, 17 May 2013, Manuel Quiñones wrote:
>>
>> 2013/5/17 Daniel Narvaez :
>> > Hello,
>> >
>> > I created a bit of a roadmap for 0.100 on github, to give some
>> > information
>> > about the release status and deadlines.
>> >
>> > https://github.com/sugarlabs/roadmap/issues/milestones
>> >
>> > The milestones has informations about dates/freezes. The issues contains
>> > information about the new features we are planning for 0.100.
>> >
>> > Walter, Ajay, I would appreciate if you guys to take a look to features
>> > you
>> > are leading and make sure the status informations I added are good. It
>> > should be really quick. If you know the time frame you are targeting it
>> > would be nice to update the milestone to match that. Right now they are
>> > are
>> > all targeted 0.99.0. I will try to keep the list updated, but help from
>> > the
>> > feature owners would be of course appreciated.
>> >
>> > I will add a link on developer.sugarlabs.org after you guys had a chance
>> > to
>> > take a look.
>> >
>> > We are using the awesome github task lists for HTML activities, to
>> > provide a
>> > TODO for people which want to jump in
>> >
>> > https://github.com/sugarlabs/roadmap/issues/8
>> >
>> > Feel free to do the same if there is any other feature where we need
>> > contributors.
>>
>> Excellent Daniel.  I have added some tasks for the UI under
>> sugar-html-graphics section.  I will try to provide one image per
>> widget, but in any case collaborators should be comparing visually
>> with current Sugar.
>>
>>
>>
>> --
>> .. manuq ..
>
>
>
> --
> Daniel Narvaez
>



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

Re: [Sugar-devel] 0.100 roadmap

[Daniel Narvaez]

Thanks. That looks great!

I wonder if it would be worth to document the desired visuals and behaviour
while writing the code. It shouldn't take a lot of time and it could be a
decent UI spec, useful to testers and designers too. Docco seems right for
this kind of stuff and keeping the UI spec in the code should ensure it
stays updated.

Thanks to Walter too for providing updates!

On Friday, 17 May 2013, Manuel Quiñones wrote:

> 2013/5/17 Daniel Narvaez >:
> > Hello,
> >
> > I created a bit of a roadmap for 0.100 on github, to give some
> information
> > about the release status and deadlines.
> >
> > https://github.com/sugarlabs/roadmap/issues/milestones
> >
> > The milestones has informations about dates/freezes. The issues contains
> > information about the new features we are planning for 0.100.
> >
> > Walter, Ajay, I would appreciate if you guys to take a look to features
> you
> > are leading and make sure the status informations I added are good. It
> > should be really quick. If you know the time frame you are targeting it
> > would be nice to update the milestone to match that. Right now they are
> are
> > all targeted 0.99.0. I will try to keep the list updated, but help from
> the
> > feature owners would be of course appreciated.
> >
> > I will add a link on developer.sugarlabs.org after you guys had a
> chance to
> > take a look.
> >
> > We are using the awesome github task lists for HTML activities, to
> provide a
> > TODO for people which want to jump in
> >
> > https://github.com/sugarlabs/roadmap/issues/8
> >
> > Feel free to do the same if there is any other feature where we need
> > contributors.
>
> Excellent Daniel.  I have added some tasks for the UI under
> sugar-html-graphics section.  I will try to provide one image per
> widget, but in any case collaborators should be comparing visually
> with current Sugar.
>
>
>
> --
> .. manuq ..
>


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

Re: [Sugar-devel] 0.100 roadmap

[Manuel Quiñones]

2013/5/17 Daniel Narvaez :
> Hello,
>
> I created a bit of a roadmap for 0.100 on github, to give some information
> about the release status and deadlines.
>
> https://github.com/sugarlabs/roadmap/issues/milestones
>
> The milestones has informations about dates/freezes. The issues contains
> information about the new features we are planning for 0.100.
>
> Walter, Ajay, I would appreciate if you guys to take a look to features you
> are leading and make sure the status informations I added are good. It
> should be really quick. If you know the time frame you are targeting it
> would be nice to update the milestone to match that. Right now they are are
> all targeted 0.99.0. I will try to keep the list updated, but help from the
> feature owners would be of course appreciated.
>
> I will add a link on developer.sugarlabs.org after you guys had a chance to
> take a look.
>
> We are using the awesome github task lists for HTML activities, to provide a
> TODO for people which want to jump in
>
> https://github.com/sugarlabs/roadmap/issues/8
>
> Feel free to do the same if there is any other feature where we need
> contributors.

Excellent Daniel.  I have added some tasks for the UI under
sugar-html-graphics section.  I will try to provide one image per
widget, but in any case collaborators should be comparing visually
with current Sugar.



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

Re: [Sugar-devel] [sugar-build] Command line change

[Alan Jhonn Aguiar Schwyn]

Ok. Thanks!

Date: Fri, 17 May 2013 14:20:18 +0200
From: dwnarv...@gmail.com
To: alan...@hotmail.com
CC: sugar-devel@lists.sugarlabs.org
Subject: Re: [Sugar-devel] [sugar-build] Command line change

It was an ubuntu/debian bug but the latest virtualenv release works. So I 
upgraded and this issue is fixed. Waiting for the builds to complete though...



On 17 May 2013 08:38, Daniel Narvaez  wrote:

The command line changes are mostly a side of the code changes I made to make 
it possible to use the bulk of sugar-build in non-sugar projects.
I didn't expect things to regress this badly and I'm afk at the moment so I 
can't do much. Is python 3 the default on your distro? (It's a weird error but 
it happens on the buildbot so it should be easy to debug when I'm back on a 
keyboard).



On Friday, 17 May 2013, Alan Jhonn Aguiar Schwyn  wrote:



Why this changes? The other works fine!!
Now I have:
alan@alan-pc:~/Documentos/GIT/sugar-build/sugar-build$ ./osbuild pullInstalling 
virtualenv...

Traceback (most recent call last):  File 
"/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
 line 2560, in main()

  File 
"/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
 line 964, in mainnever_download=options.never_download)  File 
"/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
 line 1074, in create_environment

search_dirs=search_dirs, never_download=never_download)  File 
"/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
 line 611, in install_setuptools

search_dirs=search_dirs, never_download=never_download)  File 
"/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
 line 583, in _install_req

cwd=cwd)  File 
"/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
 line 1042, in call_subprocess% (cmd_desc, proc.returncode))

OSError: Command /home/alan/Documento...x/install/bin/python -c 
"#!python\"\"\"Bootstra...sys.argv[1:])







" /home/alan/Documento...ols-0.6c11-py2.7.egg failed with error code 1Traceback 
(most recent call last):  File "./osbuild", line 130, in main()

  File "./osbuild", line 108, in maincreate_virtualenv()  File "./osbuild", 
line 68, in create_virtualenvget_virtualenv_dir()])  File 
"/usr/lib/python2.7/subprocess.py", line 542, in check_call

raise CalledProcessError(retcode, cmd)subprocess.CalledProcessError: 
Command '['python', 
'/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py',
 '-q', '--system-site-packages', 
'/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/install']' returned 
non-zero exit status 1



Date: Fri, 17 May 2013 02:14:06 +0200
From: dwnarv...@gmail.com
To: sugar-devel@lists.sugarlabs.org

Subject: [Sugar-devel] [sugar-build] Command line change

Hello,

I changed a bit the sugar-build command line. I updated the docs, they should 
be up soon. In short, instead of "make command" you can now either




  ./osbuild command

or

  ./osbuild
  (this enters the shell)
  command1
  command2
  ...

The actual commands and options are all the same.



-- 
Daniel Narvaez



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


-- 
Daniel Narvaez




-- 
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

[Sugar-devel] 0.100 roadmap

[Daniel Narvaez]

Hello,

I created a bit of a roadmap for 0.100 on github, to give some information
about the release status and deadlines.

https://github.com/sugarlabs/roadmap/issues/milestones

The milestones has informations about dates/freezes. The issues contains
information about the new features we are planning for 0.100.

Walter, Ajay, I would appreciate if you guys to take a look to features you
are leading and make sure the status informations I added are good. It
should be really quick. If you know the time frame you are targeting it
would be nice to update the milestone to match that. Right now they are are
all targeted 0.99.0. I will try to keep the list updated, but help from the
feature owners would be of course appreciated.

I will add a link on developer.sugarlabs.org after you guys had a chance to
take a look.

We are using the awesome github task lists for HTML activities, to provide
a TODO for people which want to jump in

https://github.com/sugarlabs/roadmap/issues/8

Feel free to do the same if there is any other feature where we need
contributors.

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

Re: [Sugar-devel] [Marketing] Sugar 0.100 or 1.0

[Daniel Narvaez]

Thanks so much for the well thought feedback, Sean.

On 17 May 2013 18:04, Sean DALY  wrote:

> We can't go with 1.0 unless we change the numbering system.
>
> The current system means it will take another decade to get to v3.0. I and
> perhaps others will have far more grey hair by then.
>

Couple of things:

1 So this has never been discussed before with developers, but my opinion
is that as soon as we have some automated tests in place we should move to
continuous development. Which means version numbers would become pretty
much irrelevant to developers. I'm not sure what other thinks and we
probably shouldn't discuss that here to not sidetrack the thread.

2 All the power to marketing on this. I would be fine with you guys
unilaterally choosing release numbers :)

I proposed several years ago that the developer version numbers (not to
> mention the OLPC OS version numbers) be separated from the marketing
> version numbers, since the dev version numbers are unmarketable. Developer
> resistance at the time was ferocious, a symptom of how marketing is widely
> considered irrelevant in the F/LOSS universe.
>
> We therefore reoriented version numbering for Sugar on a Stick "v6", which
> we rebaptized "v1 Strawberry". This strategy helped us obtain very wide
> press coverage at the time, since journalists and analysts (as intended)
> understood that release as "Sugar v1, a year after the spinoff from OLPC".
> This was appropriate, because Sugar was already shipping in production to
> hundreds of thousands of children.
>

There is an important point here. At the moment the release we are talking
about is not a finished product, which is what you seem to think about.
It's just something you can take a make a finished product with.

If we want to market a finished product we need to decide what that is. Is
it Sugar on a Stick?

Today, communicating a v1 of Sugar is problematic, *unless* it is
> associated with a platform change, e.g. the transition to HTML-based (and
> ultimately Android-compatible) Activities; or presented as positioning
> Sugar for tablets; our narrative would be "a fresh start".
>

I'm not too convinced the next release will be a compelling demo of the
html libraries. We don't have much time to write new cool activities
mostly. Maybe we can still market the switch, I'm not keen about that but I
don't know.


> In terms of timing, it's far more important to offer real change with a v1
> than to meet a self-imposed deadline; if more time is needed, by all means
> it should be taken.
>

I think in a continuous development work we would basically "release" when
we are ready. The code would be ready all the time and we would just decide
when stuff is cool enough to make noise about it.

Though realistically for development I don't think this is the time to
abandon 6 months time based released. I suggest we discuss that after this
release. It shouldn't make much difference for marketing, devel release
doesn't even need to be "public".


> A functioning HTML5 based toolkit, adapting to the form factor change
> towards tablets, Android compatibility (whatever form that may take),
> perhaps even an OEM partnership with Raspberry Pi Foundation or Google
> (Chromebook) or a social media giant, would not only greatly raise
> awareness, but provide a springboard for serious funding.
>

Is anyone working on those partnerships? Is there anything developers can
do to help them? Other than keeping to improve the software of course. And
I'm sure a solid "port" to the Raspberry might be useful but... we need to
chose what to focus on, it should something which has solid chances to
happen.


> At the same time, it will be vital to communicate our level of ongoing
> support (in the wide sense) to the existing installed base which of course
> will include the XO-4 recipients as it starts shipping.
>
> I feel that 0.100 is even more unmarketable than 0.98. However, as a
> developer version number tucked away under the hood, I'd have no objection
> to that if it is helpful to getting the job done while a more
> understandable number is communicated to press and analysts.
>

So perhaps we need to figure out what 1.0 (or whatever name marketing would
like) should be and then developers will figure out the best way to make it
happen :)

The most pressing question to me is what it is that we are marketing
exactly. Is it Sugar on a Stick? Is it the upstream code release (is that
even marketable)? Or what is it?

I hope it's clear I would like marketing to have more of a say in the
development direction. I don't know where we want to go, but I wish you
guys could help us to figure that out.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Marketing] Sugar 0.100 or 1.0

[Sean DALY]

We can't go with 1.0 unless we change the numbering system.

The current system means it will take another decade to get to v3.0. I and
perhaps others will have far more grey hair by then.

I proposed several years ago that the developer version numbers (not to
mention the OLPC OS version numbers) be separated from the marketing
version numbers, since the dev version numbers are unmarketable. Developer
resistance at the time was ferocious, a symptom of how marketing is widely
considered irrelevant in the F/LOSS universe.

We therefore reoriented version numbering for Sugar on a Stick "v6", which
we rebaptized "v1 Strawberry". This strategy helped us obtain very wide
press coverage at the time, since journalists and analysts (as intended)
understood that release as "Sugar v1, a year after the spinoff from OLPC".
This was appropriate, because Sugar was already shipping in production to
hundreds of thousands of children.

Today, communicating a v1 of Sugar is problematic, *unless* it is
associated with a platform change, e.g. the transition to HTML-based (and
ultimately Android-compatible) Activities; or presented as positioning
Sugar for tablets; our narrative would be "a fresh start".

In terms of timing, it's far more important to offer real change with a v1
than to meet a self-imposed deadline; if more time is needed, by all means
it should be taken. A functioning HTML5 based toolkit, adapting to the form
factor change towards tablets, Android compatibility (whatever form that
may take), perhaps even an OEM partnership with Raspberry Pi Foundation or
Google (Chromebook) or a social media giant, would not only greatly raise
awareness, but provide a springboard for serious funding.

At the same time, it will be vital to communicate our level of ongoing
support (in the wide sense) to the existing installed base which of course
will include the XO-4 recipients as it starts shipping.

I feel that 0.100 is even more unmarketable than 0.98. However, as a
developer version number tucked away under the hood, I'd have no objection
to that if it is helpful to getting the job done while a more
understandable number is communicated to press and analysts.

Sean
Sugar Labs Marketing Coordinator





On Fri, May 17, 2013 at 3:21 PM, Walter Bender wrote:

> Perfection is the enemy of the good.
>
> On Fri, May 17, 2013 at 9:07 AM, Daniel Narvaez 
> wrote:
> > Hello,
> >
> > we need to decide if we want the next release to be 1.0 or 0.100.
> >
> > Here is the features we are planning for it.
> >
> > * Develop an HTML5 based toolkit for activities
> >
> > * 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
> >
> >
> > It's a bit of weird situation because code wise we are not really 1.0
> ready.
> > We are developing a new toolkit and the old one could use an API
> cleanup. On
> > the other hand we are deployed to millions of users.
> >
> > Personally I don't really have a strong feeling. If the marketing team
> sees
> > an opportunity in a 1.0 in October with the above feature list I'd say
> to go
> > ahead with it even if from a developer point of view we are not ready.
> > Otherwise we could delay it at least another cycle.
>
> I think the marketing team had already reached consensus about 1.0.
> But maybe Sean can chime in.
>
>
> >
> > --
> > Daniel Narvaez
> >
> > ___
> > Marketing mailing list
> > market...@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/marketing
> >
>
> Plus, I think .100 is confusing.
>
> -walter
>
> --
> 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] Sugar 0.100 or 1.0

[Daniel Narvaez]

It seems like we have agreement on going 1.0 so far. Unless someone speak
up I'm going to make that the plan in a couple of days.


On 17 May 2013 15:07, Daniel Narvaez  wrote:

> Hello,
>
> we need to decide if we want the next release to be 1.0 or 0.100.
>
> Here is the features we are planning for it.
>
> * Develop an HTML5 based toolkit for activities
>
> * 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
>
>
> It's a bit of weird situation because code wise we are not really 1.0
> ready. We are developing a new toolkit and the old one could use an API
> cleanup. On the other hand we are deployed to millions of users.
>
> Personally I don't really have a strong feeling. If the marketing team
> sees an opportunity in a 1.0 in October with the above feature list I'd say
> to go ahead with it even if from a developer point of view we are not
> ready. Otherwise we could delay it at least another cycle.
>
> --
> Daniel Narvaez
>



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

Re: [Sugar-devel] Requiring test coverage for new code

[Daniel Narvaez]

On 17 May 2013 15:53, Manuel Quiñones  wrote:

> And for the html sugar, we should do full coverage testing.
>

You mean make check enforced 100% coverage? :) I would love it.

You proposed it, so people hate should be directed to you! I did it with a
project I and always felt sort of guilty about people swearing while trying
to cover every single little code branch :P
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] [Marketing] Sugar 0.100 or 1.0

[Manuel Quiñones]

Nice phrase Alan :)

I agree with all, let's name it 1.0 .

2013/5/17 Alan Kay :
> "Better" and "Perfect" are the enemies of "What Is Needed"
>
> 
> From: Walter Bender 
> To: Daniel Narvaez ; Sean DALY 
> Cc: Sugar Labs Marketing ;
> "sugar-devel@lists.sugarlabs.org" ; iaep
> 
> Sent: Friday, May 17, 2013 6:21 AM
> Subject: Re: [IAEP] [Marketing] Sugar 0.100 or 1.0
>
> Perfection is the enemy of the good.
>
> On Fri, May 17, 2013 at 9:07 AM, Daniel Narvaez  wrote:
>> Hello,
>>
>> we need to decide if we want the next release to be 1.0 or 0.100.
>>
>> Here is the features we are planning for it.
>>
>> * Develop an HTML5 based toolkit for activities
>>
>> * 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
>>
>>
>> It's a bit of weird situation because code wise we are not really 1.0
>> ready.
>> We are developing a new toolkit and the old one could use an API cleanup.
>> On
>> the other hand we are deployed to millions of users.
>>
>> Personally I don't really have a strong feeling. If the marketing team
>> sees
>> an opportunity in a 1.0 in October with the above feature list I'd say to
>> go
>> ahead with it even if from a developer point of view we are not ready.
>> Otherwise we could delay it at least another cycle.
>
> I think the marketing team had already reached consensus about 1.0.
> But maybe Sean can chime in.
>
>
>>
>> --
>> Daniel Narvaez
>>
>> ___
>> Marketing mailing list
>> market...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/marketing
>>
>
> Plus, I think .100 is confusing.
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



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

Re: [Sugar-devel] Requiring test coverage for new code

[Manuel Quiñones]

Sorry for not answering yet, I was in doubt.because of the "raising
the bar" consequence.

I really missed unit-testings in Sugar when the GTK3 port was made.  I
considered starting doing them at that time, but looked like a lot of
work.  Adding testing to an already written system can be a pain.  But
if we progressively do it, that would be great.

So I vote for 2.

And for the html sugar, we should do full coverage testing.


2013/5/17 Gonzalo Odiard :
> May be I am old fashion, but requesting mandatory automated tests for all
> the changes is not a good idea.
> We are a small team. And we don't have a problem of regressions.
> May be, with the new  web api, with the many changes we will have in the
> next months,
> is a good idea.
>
> Gonzalo
>
>
> On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez 
> wrote:
>>
>> Oh sorry, I suppose I should have made that clear :) I'm talking about
>> automated tests, we have a few examples of them in the tree
>>
>> https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
>> https://github.com/sugarlabs/sugar/tree/master/tests
>> https://github.com/sugarlabs/sugar-build/tree/master/tests
>>
>>
>>
>> On 17 May 2013 15:16, Simon Schampijer  wrote:
>>>
>>> How does the test coverage looks like? Human testing or automated tests?
>>>
>>> Thanks,
>>>Simon
>>>
>>>
>>> On 05/17/2013 03:13 PM, Daniel Narvaez wrote:

 Simon, Manuel,

 any feedback about this? I see a few possible levels

 1 Everything, bugfixes included
 2 Every feature patch
 3 Every patch to the new html/javascript code
 4 Nothing, leave it to the contributor willingness

 I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
 code is landing and the more code without tests we need to maintain the
 worst the quality situation will get. I guess 3 would also be a
 possibility
 if we want to try it out and increase gradually.


 On 13 May 2013 00:28, Daniel Narvaez  wrote:

> Hello,
>
> I'd like to propose to make it a requirement, enforced by code reviews,
> to
> provide good test coverage when submitting new code. It will raise the
> bar
> for contributions but it's essential if we want to improve quality (and
> I
> think we have to). I can add a paragraph about it to sugar-docs, if we
> have
> consensus.
>
> A few details:
>
> * What to do with patches which have been already submitted? I think it
> really depends on the patch, so I'd leave it to the reviewer
> discretion.
> * Should this apply to bug fixes? I tend to think it should, we are not
> in
> a particularly active bug fixing period now, so it's a good time to
> start
> with those too.
> * Cannot apply to javascript code yet, because the infra is not in
> place.
> Though writing the infra is on the short time priorities, so this
> should
> change soon.
> * Cannot apply to activities because we are missing infra bits. It
> would
> not be too hard to add them, but I think we should focus on html
> activities
> now.
>
>
> --
> Daniel Narvaez
>
>


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



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

Re: [Sugar-devel] Requiring test coverage for new code

[Daniel Narvaez]

IMO being a small team makes it an even better idea :) If you get used to
it, I think you write solid new code faster _with_ tests than without.

I disagree we don't have a regression problem. Just think of the settings
stuff that has been broken for months. Also we are scared to refactor stuff
because it might cause bugs. My feeling is that we don't find many
regressions just because we don't do enough human testing.

I admit the small team argument might be valid against doing 1. Writing
tests for existing code helps with regression but it is time consuming. And
given the general quality of the code base slowing down bug fixes might not
be a good idea. I really don't have a strong feeling about this tough, I
guess we have maintainers to take this kind of decisions :P


On 17 May 2013 15:36, Gonzalo Odiard  wrote:

> May be I am old fashion, but requesting mandatory automated tests for all
> the changes is not a good idea.
> We are a small team. And we don't have a problem of regressions.
> May be, with the new  web api, with the many changes we will have in the
> next months,
> is a good idea.
>
> Gonzalo
>
>
> On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez wrote:
>
>> Oh sorry, I suppose I should have made that clear :) I'm talking about
>> automated tests, we have a few examples of them in the tree
>>
>> https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
>> https://github.com/sugarlabs/sugar/tree/master/tests
>> https://github.com/sugarlabs/sugar-build/tree/master/tests
>>
>>
>>
>> On 17 May 2013 15:16, Simon Schampijer  wrote:
>>
>>> How does the test coverage looks like? Human testing or automated tests?
>>>
>>> Thanks,
>>>Simon
>>>
>>>
>>> On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
>>>
 Simon, Manuel,

 any feedback about this? I see a few possible levels

 1 Everything, bugfixes included
 2 Every feature patch
 3 Every patch to the new html/javascript code
 4 Nothing, leave it to the contributor willingness

 I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
 code is landing and the more code without tests we need to maintain the
 worst the quality situation will get. I guess 3 would also be a
 possibility
 if we want to try it out and increase gradually.


 On 13 May 2013 00:28, Daniel Narvaez  wrote:

  Hello,
>
> I'd like to propose to make it a requirement, enforced by code
> reviews, to
> provide good test coverage when submitting new code. It will raise the
> bar
> for contributions but it's essential if we want to improve quality
> (and I
> think we have to). I can add a paragraph about it to sugar-docs, if we
> have
> consensus.
>
> A few details:
>
> * What to do with patches which have been already submitted? I think it
> really depends on the patch, so I'd leave it to the reviewer
> discretion.
> * Should this apply to bug fixes? I tend to think it should, we are
> not in
> a particularly active bug fixing period now, so it's a good time to
> start
> with those too.
> * Cannot apply to javascript code yet, because the infra is not in
> place.
> Though writing the infra is on the short time priorities, so this
> should
> change soon.
> * Cannot apply to activities because we are missing infra bits. It
> would
> not be too hard to add them, but I think we should focus on html
> activities
> now.
>
>
> --
> Daniel Narvaez
>
>
>


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


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

Re: [Sugar-devel] Requiring test coverage for new code

[Gonzalo Odiard]

May be I am old fashion, but requesting mandatory automated tests for all
the changes is not a good idea.
We are a small team. And we don't have a problem of regressions.
May be, with the new  web api, with the many changes we will have in the
next months,
is a good idea.

Gonzalo


On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez wrote:

> Oh sorry, I suppose I should have made that clear :) I'm talking about
> automated tests, we have a few examples of them in the tree
>
> https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
> https://github.com/sugarlabs/sugar/tree/master/tests
> https://github.com/sugarlabs/sugar-build/tree/master/tests
>
>
>
> On 17 May 2013 15:16, Simon Schampijer  wrote:
>
>> How does the test coverage looks like? Human testing or automated tests?
>>
>> Thanks,
>>Simon
>>
>>
>> On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
>>
>>> Simon, Manuel,
>>>
>>> any feedback about this? I see a few possible levels
>>>
>>> 1 Everything, bugfixes included
>>> 2 Every feature patch
>>> 3 Every patch to the new html/javascript code
>>> 4 Nothing, leave it to the contributor willingness
>>>
>>> I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
>>> code is landing and the more code without tests we need to maintain the
>>> worst the quality situation will get. I guess 3 would also be a
>>> possibility
>>> if we want to try it out and increase gradually.
>>>
>>>
>>> On 13 May 2013 00:28, Daniel Narvaez  wrote:
>>>
>>>  Hello,

 I'd like to propose to make it a requirement, enforced by code reviews,
 to
 provide good test coverage when submitting new code. It will raise the
 bar
 for contributions but it's essential if we want to improve quality (and
 I
 think we have to). I can add a paragraph about it to sugar-docs, if we
 have
 consensus.

 A few details:

 * What to do with patches which have been already submitted? I think it
 really depends on the patch, so I'd leave it to the reviewer discretion.
 * Should this apply to bug fixes? I tend to think it should, we are not
 in
 a particularly active bug fixing period now, so it's a good time to
 start
 with those too.
 * Cannot apply to javascript code yet, because the infra is not in
 place.
 Though writing the infra is on the short time priorities, so this should
 change soon.
 * Cannot apply to activities because we are missing infra bits. It would
 not be too hard to add them, but I think we should focus on html
 activities
 now.


 --
 Daniel Narvaez



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

Re: [Sugar-devel] [IAEP] [Marketing] Sugar 0.100 or 1.0

[Alan Kay]

"Better" and "Perfect" are the enemies of "What Is Needed"



>
> From: Walter Bender 
>To: Daniel Narvaez ; Sean DALY  
>Cc: Sugar Labs Marketing ; 
>"sugar-devel@lists.sugarlabs.org" ; iaep 
> 
>Sent: Friday, May 17, 2013 6:21 AM
>Subject: Re: [IAEP] [Marketing] Sugar 0.100 or 1.0
> 
>
>Perfection is the enemy of the good.
>
>On Fri, May 17, 2013 at 9:07 AM, Daniel Narvaez  wrote:
>> Hello,
>>
>> we need to decide if we want the next release to be 1.0 or 0.100.
>>
>> Here is the features we are planning for it.
>>
>> * Develop an HTML5 based toolkit for activities
>>
>> * 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
>>
>>
>> It's a bit of weird situation because code wise we are not really 1.0 ready.
>> We are developing a new toolkit and the old one could use an API cleanup. On
>> the other hand we are deployed to millions of users.
>>
>> Personally I don't really have a strong feeling. If the marketing team sees
>> an opportunity in a 1.0 in October with the above feature list I'd say to go
>> ahead with it even if from a developer point of view we are not ready.
>> Otherwise we could delay it at least another cycle.
>
>I think the marketing team had already reached consensus about 1.0.
>But maybe Sean can chime in.
>
>
>>
>> --
>> Daniel Narvaez
>>
>> ___
>> Marketing mailing list
>> market...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/marketing
>>
>
>Plus, I think .100 is confusing.
>
>-walter
>
>--
>Walter Bender
>Sugar Labs
>http://www.sugarlabs.org
>___
>IAEP -- It's An Education Project (not a laptop project!)
>i...@lists.sugarlabs.org
>http://lists.sugarlabs.org/listinfo/iaep
>
>
>___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Requiring test coverage for new code

[Simon Schampijer]

Ok, then I would say (1) everything.

Simon

On 05/17/2013 03:23 PM, Daniel Narvaez wrote:

Oh sorry, I suppose I should have made that clear :) I'm talking about
automated tests, we have a few examples of them in the tree

https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
https://github.com/sugarlabs/sugar/tree/master/tests
https://github.com/sugarlabs/sugar-build/tree/master/tests



On 17 May 2013 15:16, Simon Schampijer  wrote:


How does the test coverage looks like? Human testing or automated tests?

Thanks,
Simon


On 05/17/2013 03:13 PM, Daniel Narvaez wrote:


Simon, Manuel,

any feedback about this? I see a few possible levels

1 Everything, bugfixes included
2 Every feature patch
3 Every patch to the new html/javascript code
4 Nothing, leave it to the contributor willingness

I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
code is landing and the more code without tests we need to maintain the
worst the quality situation will get. I guess 3 would also be a
possibility
if we want to try it out and increase gradually.


On 13 May 2013 00:28, Daniel Narvaez  wrote:

  Hello,


I'd like to propose to make it a requirement, enforced by code reviews,
to
provide good test coverage when submitting new code. It will raise the
bar
for contributions but it's essential if we want to improve quality (and I
think we have to). I can add a paragraph about it to sugar-docs, if we
have
consensus.

A few details:

* What to do with patches which have been already submitted? I think it
really depends on the patch, so I'd leave it to the reviewer discretion.
* Should this apply to bug fixes? I tend to think it should, we are not
in
a particularly active bug fixing period now, so it's a good time to start
with those too.
* Cannot apply to javascript code yet, because the infra is not in place.
Though writing the infra is on the short time priorities, so this should
change soon.
* Cannot apply to activities because we are missing infra bits. It would
not be too hard to add them, but I think we should focus on html
activities
now.


--
Daniel Narvaez













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

Re: [Sugar-devel] Requiring test coverage for new code

[Daniel Narvaez]

I'm happy to provide guidance on this (for as much time free time I have
available for sugar).


On 17 May 2013 15:23, Walter Bender  wrote:

> +1 to adding tests to all new features, but some guidance on what
> these tests should look like is necessary.
>
> -walter
>
> On Fri, May 17, 2013 at 9:16 AM, Simon Schampijer 
> wrote:
> > How does the test coverage looks like? Human testing or automated tests?
> >
> > Thanks,
> >Simon
> >
> >
> > On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
> >>
> >> Simon, Manuel,
> >>
> >> any feedback about this? I see a few possible levels
> >>
> >> 1 Everything, bugfixes included
> >> 2 Every feature patch
> >> 3 Every patch to the new html/javascript code
> >> 4 Nothing, leave it to the contributor willingness
> >>
> >> I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
> >> code is landing and the more code without tests we need to maintain the
> >> worst the quality situation will get. I guess 3 would also be a
> >> possibility
> >> if we want to try it out and increase gradually.
> >>
> >>
> >> On 13 May 2013 00:28, Daniel Narvaez  wrote:
> >>
> >>> Hello,
> >>>
> >>> I'd like to propose to make it a requirement, enforced by code reviews,
> >>> to
> >>> provide good test coverage when submitting new code. It will raise the
> >>> bar
> >>> for contributions but it's essential if we want to improve quality
> (and I
> >>> think we have to). I can add a paragraph about it to sugar-docs, if we
> >>> have
> >>> consensus.
> >>>
> >>> A few details:
> >>>
> >>> * What to do with patches which have been already submitted? I think it
> >>> really depends on the patch, so I'd leave it to the reviewer
> discretion.
> >>> * Should this apply to bug fixes? I tend to think it should, we are not
> >>> in
> >>> a particularly active bug fixing period now, so it's a good time to
> start
> >>> with those too.
> >>> * Cannot apply to javascript code yet, because the infra is not in
> place.
> >>> Though writing the infra is on the short time priorities, so this
> should
> >>> change soon.
> >>> * Cannot apply to activities because we are missing infra bits. It
> would
> >>> not be too hard to add them, but I think we should focus on html
> >>> activities
> >>> now.
> >>>
> >>>
> >>> --
> >>> Daniel Narvaez
> >>>
> >>>
> >>
> >>
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>



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

Re: [Sugar-devel] Requiring test coverage for new code

[Daniel Narvaez]

Oh sorry, I suppose I should have made that clear :) I'm talking about
automated tests, we have a few examples of them in the tree

https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
https://github.com/sugarlabs/sugar/tree/master/tests
https://github.com/sugarlabs/sugar-build/tree/master/tests



On 17 May 2013 15:16, Simon Schampijer  wrote:

> How does the test coverage looks like? Human testing or automated tests?
>
> Thanks,
>Simon
>
>
> On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
>
>> Simon, Manuel,
>>
>> any feedback about this? I see a few possible levels
>>
>> 1 Everything, bugfixes included
>> 2 Every feature patch
>> 3 Every patch to the new html/javascript code
>> 4 Nothing, leave it to the contributor willingness
>>
>> I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
>> code is landing and the more code without tests we need to maintain the
>> worst the quality situation will get. I guess 3 would also be a
>> possibility
>> if we want to try it out and increase gradually.
>>
>>
>> On 13 May 2013 00:28, Daniel Narvaez  wrote:
>>
>>  Hello,
>>>
>>> I'd like to propose to make it a requirement, enforced by code reviews,
>>> to
>>> provide good test coverage when submitting new code. It will raise the
>>> bar
>>> for contributions but it's essential if we want to improve quality (and I
>>> think we have to). I can add a paragraph about it to sugar-docs, if we
>>> have
>>> consensus.
>>>
>>> A few details:
>>>
>>> * What to do with patches which have been already submitted? I think it
>>> really depends on the patch, so I'd leave it to the reviewer discretion.
>>> * Should this apply to bug fixes? I tend to think it should, we are not
>>> in
>>> a particularly active bug fixing period now, so it's a good time to start
>>> with those too.
>>> * Cannot apply to javascript code yet, because the infra is not in place.
>>> Though writing the infra is on the short time priorities, so this should
>>> change soon.
>>> * Cannot apply to activities because we are missing infra bits. It would
>>> not be too hard to add them, but I think we should focus on html
>>> activities
>>> now.
>>>
>>>
>>> --
>>> Daniel Narvaez
>>>
>>>
>>>
>>
>>
>


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

Re: [Sugar-devel] Requiring test coverage for new code

[Walter Bender]

+1 to adding tests to all new features, but some guidance on what
these tests should look like is necessary.

-walter

On Fri, May 17, 2013 at 9:16 AM, Simon Schampijer  wrote:
> How does the test coverage looks like? Human testing or automated tests?
>
> Thanks,
>Simon
>
>
> On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
>>
>> Simon, Manuel,
>>
>> any feedback about this? I see a few possible levels
>>
>> 1 Everything, bugfixes included
>> 2 Every feature patch
>> 3 Every patch to the new html/javascript code
>> 4 Nothing, leave it to the contributor willingness
>>
>> I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
>> code is landing and the more code without tests we need to maintain the
>> worst the quality situation will get. I guess 3 would also be a
>> possibility
>> if we want to try it out and increase gradually.
>>
>>
>> On 13 May 2013 00:28, Daniel Narvaez  wrote:
>>
>>> Hello,
>>>
>>> I'd like to propose to make it a requirement, enforced by code reviews,
>>> to
>>> provide good test coverage when submitting new code. It will raise the
>>> bar
>>> for contributions but it's essential if we want to improve quality (and I
>>> think we have to). I can add a paragraph about it to sugar-docs, if we
>>> have
>>> consensus.
>>>
>>> A few details:
>>>
>>> * What to do with patches which have been already submitted? I think it
>>> really depends on the patch, so I'd leave it to the reviewer discretion.
>>> * Should this apply to bug fixes? I tend to think it should, we are not
>>> in
>>> a particularly active bug fixing period now, so it's a good time to start
>>> with those too.
>>> * Cannot apply to javascript code yet, because the infra is not in place.
>>> Though writing the infra is on the short time priorities, so this should
>>> change soon.
>>> * Cannot apply to activities because we are missing infra bits. It would
>>> not be too hard to add them, but I think we should focus on html
>>> activities
>>> now.
>>>
>>>
>>> --
>>> Daniel Narvaez
>>>
>>>
>>
>>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [Marketing] Sugar 0.100 or 1.0

[Walter Bender]

Perfection is the enemy of the good.

On Fri, May 17, 2013 at 9:07 AM, Daniel Narvaez  wrote:
> Hello,
>
> we need to decide if we want the next release to be 1.0 or 0.100.
>
> Here is the features we are planning for it.
>
> * Develop an HTML5 based toolkit for activities
>
> * 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
>
>
> It's a bit of weird situation because code wise we are not really 1.0 ready.
> We are developing a new toolkit and the old one could use an API cleanup. On
> the other hand we are deployed to millions of users.
>
> Personally I don't really have a strong feeling. If the marketing team sees
> an opportunity in a 1.0 in October with the above feature list I'd say to go
> ahead with it even if from a developer point of view we are not ready.
> Otherwise we could delay it at least another cycle.

I think the marketing team had already reached consensus about 1.0.
But maybe Sean can chime in.


>
> --
> Daniel Narvaez
>
> ___
> Marketing mailing list
> market...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/marketing
>

Plus, I think .100 is confusing.

-walter

--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Requiring test coverage for new code

[Simon Schampijer]

How does the test coverage looks like? Human testing or automated tests?

Thanks,
   Simon

On 05/17/2013 03:13 PM, Daniel Narvaez wrote:

Simon, Manuel,

any feedback about this? I see a few possible levels

1 Everything, bugfixes included
2 Every feature patch
3 Every patch to the new html/javascript code
4 Nothing, leave it to the contributor willingness

I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
code is landing and the more code without tests we need to maintain the
worst the quality situation will get. I guess 3 would also be a possibility
if we want to try it out and increase gradually.


On 13 May 2013 00:28, Daniel Narvaez  wrote:


Hello,

I'd like to propose to make it a requirement, enforced by code reviews, to
provide good test coverage when submitting new code. It will raise the bar
for contributions but it's essential if we want to improve quality (and I
think we have to). I can add a paragraph about it to sugar-docs, if we have
consensus.

A few details:

* What to do with patches which have been already submitted? I think it
really depends on the patch, so I'd leave it to the reviewer discretion.
* Should this apply to bug fixes? I tend to think it should, we are not in
a particularly active bug fixing period now, so it's a good time to start
with those too.
* Cannot apply to javascript code yet, because the infra is not in place.
Though writing the infra is on the short time priorities, so this should
change soon.
* Cannot apply to activities because we are missing infra bits. It would
not be too hard to add them, but I think we should focus on html activities
now.


--
Daniel Narvaez







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

Re: [Sugar-devel] [IAEP] Sugar 0.100 or 1.0

[Chris Ball]

Hi,

On Fri, May 17 2013, Daniel Narvaez wrote:
> we need to decide if we want the next release to be 1.0 or 0.100.

1.0!  It's crazy that we have a project used by millions of people
that's still pre-1.0 seven years later.  And the extra press from
calling it 1.0 will be useful to direct people towards the HTML5
push and get their help with it.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Requiring test coverage for new code

[Daniel Narvaez]

Simon, Manuel,

any feedback about this? I see a few possible levels

1 Everything, bugfixes included
2 Every feature patch
3 Every patch to the new html/javascript code
4 Nothing, leave it to the contributor willingness

I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
code is landing and the more code without tests we need to maintain the
worst the quality situation will get. I guess 3 would also be a possibility
if we want to try it out and increase gradually.


On 13 May 2013 00:28, Daniel Narvaez  wrote:

> Hello,
>
> I'd like to propose to make it a requirement, enforced by code reviews, to
> provide good test coverage when submitting new code. It will raise the bar
> for contributions but it's essential if we want to improve quality (and I
> think we have to). I can add a paragraph about it to sugar-docs, if we have
> consensus.
>
> A few details:
>
> * What to do with patches which have been already submitted? I think it
> really depends on the patch, so I'd leave it to the reviewer discretion.
> * Should this apply to bug fixes? I tend to think it should, we are not in
> a particularly active bug fixing period now, so it's a good time to start
> with those too.
> * Cannot apply to javascript code yet, because the infra is not in place.
> Though writing the infra is on the short time priorities, so this should
> change soon.
> * Cannot apply to activities because we are missing infra bits. It would
> not be too hard to add them, but I think we should focus on html activities
> now.
>
>
> --
> Daniel Narvaez
>
>


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

[Sugar-devel] Sugar 0.100 or 1.0

[Daniel Narvaez]

Hello,

we need to decide if we want the next release to be 1.0 or 0.100.

Here is the features we are planning for it.

* Develop an HTML5 based toolkit for activities

* 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


It's a bit of weird situation because code wise we are not really 1.0
ready. We are developing a new toolkit and the old one could use an API
cleanup. On the other hand we are deployed to millions of users.

Personally I don't really have a strong feeling. If the marketing team sees
an opportunity in a 1.0 in October with the above feature list I'd say to
go ahead with it even if from a developer point of view we are not ready.
Otherwise we could delay it at least another cycle.

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

Re: [Sugar-devel] [sugar-build] Command line change

[Daniel Narvaez]

It was an ubuntu/debian bug but the latest virtualenv release works. So I
upgraded and this issue is fixed. Waiting for the builds to complete
though...


On 17 May 2013 08:38, Daniel Narvaez  wrote:

> The command line changes are mostly a side of the code changes I made to
> make it possible to use the bulk of sugar-build in non-sugar projects.
>
> I didn't expect things to regress this badly and I'm afk at the moment so
> I can't do much. Is python 3 the default on your distro? (It's a weird
> error but it happens on the buildbot so it should be easy to debug when I'm
> back on a keyboard).
>
>
> On Friday, 17 May 2013, Alan Jhonn Aguiar Schwyn wrote:
>
>> Why this changes? The other works fine!!
>>
>> Now I have:
>>
>> alan@alan-pc:~/Documentos/GIT/sugar-build/sugar-build$ ./osbuild pull
>> Installing virtualenv...
>> Traceback (most recent call last):
>>   File
>> "/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
>> line 2560, in 
>> main()
>>   File
>> "/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
>> line 964, in main
>> never_download=options.never_download)
>>   File
>> "/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
>> line 1074, in create_environment
>> search_dirs=search_dirs, never_download=never_download)
>>   File
>> "/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
>> line 611, in install_setuptools
>> search_dirs=search_dirs, never_download=never_download)
>>   File
>> "/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
>> line 583, in _install_req
>> cwd=cwd)
>>   File
>> "/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py",
>> line 1042, in call_subprocess
>> % (cmd_desc, proc.returncode))
>> OSError: Command /home/alan/Documento...x/install/bin/python -c "#!python
>> \"\"\"Bootstra...sys.argv[1:])
>>
>>
>>
>>
>>
>>
>> " /home/alan/Documento...ols-0.6c11-py2.7.egg failed with error code 1
>> Traceback (most recent call last):
>>   File "./osbuild", line 130, in 
>> main()
>>   File "./osbuild", line 108, in main
>> create_virtualenv()
>>   File "./osbuild", line 68, in create_virtualenv
>> get_virtualenv_dir()])
>>   File "/usr/lib/python2.7/subprocess.py", line 542, in check_call
>> raise CalledProcessError(retcode, cmd)
>> subprocess.CalledProcessError: Command '['python',
>> '/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/cache/virtualenv-1.8.4/virtualenv.py',
>> '-q', '--system-site-packages',
>> '/home/alan/Documentos/GIT/sugar-build/sugar-build/sandbox/install']'
>> returned non-zero exit status 1
>>
>>
>> --
>> Date: Fri, 17 May 2013 02:14:06 +0200
>> From: dwnarv...@gmail.com
>> To: sugar-devel@lists.sugarlabs.org
>> Subject: [Sugar-devel] [sugar-build] Command line change
>>
>> Hello,
>>
>> I changed a bit the sugar-build command line. I updated the docs, they
>> should be up soon. In short, instead of "make command" you can now either
>>
>>   ./osbuild command
>>
>> or
>>
>>   ./osbuild
>>   (this enters the shell)
>>   command1
>>   command2
>>   ...
>>
>> The actual commands and options are all the same.
>>
>> --
>> Daniel Narvaez
>>
>> ___ Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
> --
> Daniel Narvaez
>
>


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