[Sugar-devel] Next release

[Simon Schampijer]

On 03/26/2013 01:20 PM, Walter Bender wrote:
> On Tue, Mar 26, 2013 at 8:07 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
>> Hello,
>>
>> we are pretty late in the cycle for the next release without much
>> development having been landed on the master branch. At this point I
>> think we need to consider what our options are. If we had to release 6
>> months after 0.98.0, that would be the beginning of June, thus only 2
>> months and half left. Things are even worst if we consider the GNOME
>> schedule, which have been trying to stay somewhat synced with. In fact
>> 3.8 is being released these days.
>>
>> So, here are the possibilities I see
>>
>> 1 Try to stick to the plan anyway, land the features that have been
>> developed so far and try to stabilize them in time for June.
>> 2 Focus on a polish only release for June and delay new features to
>> the next cycle.
>> 3 Skip the June release altogether, start a new 6 months cycle now.
>> Work on another stable release in parallel.
>>
>> My feeling is that 1 is not very realistic. There is very little time
>> and our maintainers and most active contributors are going to be busy
>> polishing for upcoming OLPC release. We should consider that Fedora 19
>> will stay on 0.98. So even if we manage to release in time, the
>> release won't be much distributed.
>>
>> I'm not too sure about 2 vs 3. Our maintainers haven't been getting
>> much help with the polishing phase of the release cycle and it would
>> be good to send a message to the community that it's an important part
>> of the work, by dedicating a few months exclusively to it. Though I'm
>> not too keen of blocking master for another few months, keeping code
>> which has already been submitted long ago out of the tree.
>>
>> What does everyone think?
>>
>> --
>> Daniel Narvaez
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
> I don't think it is worth pushing out a half-baked release just to
> keep on a time-based release schedule, so I agree about not going with
> option #1.
>
> Re #2, it would be good to get a feel for what polish is needed and
> what would be realistic to land. (I've been for example, trying to get
> some of the core activities better tuned for touch and screen
> rotation, but there has been little comprehensive discussion of this
> theme on devel. I doubt we'd be able to land these changes in this
> release cycle.)
>
> Re #3, personally, I think we should go with this option. We have
> extra time to make it a great release for Sugar 1.0. Can we start with
> putting together a schedule in the wiki [1].
>
> regards.
>
> -walter
>
> [1] http://wiki.sugarlabs.org/go/1.0/Roadmap (just a stub)

I would go for option #3, I like the idea of sending the 'bugfixes are 
an important part of the game" message out but I think it is good to 
keep master open. OLPC 13.2.0 will ship a polished 0.98 release, this 
release is feature based depending on a few XO-4 polish items. For 0.98 
polish this means to just get as many bug fixes in as possible, and make 
bugfix releases often enough.

Help is highly welcome on that effort of course. So this could be the 
message to pass to not only think on master and help polish the stable 
branch in parallel. This will benefit as well the upcoming Soas/Fedora 
19 release which will include that polished 0.98 version. To get a 
feeling of open items, here is a list of 0.98 regressions [1] and the 
currently tagged 0.98 bugs [2].

Back to the next unstable release, going for the September/October 2013 
release and keeping aligned with GNOME the platform we are building on 
is a good goal. As stated by different people several times, we should 
list the goals and then work together to achieve them. By limiting the 
features and/or foster around a bigger one we can foster our resources 
(I think about HTML5 activities here in particular as my favorite item 
for the next unstable release).

About the branches, there is a sucrose-0.98 branch where the stable 
release, the 0.98 polish release does come from. Unstable development 
does happen on master. Bugfixes that land in sucrose-0.98 do land in 
master first and get cherry-picked to sucrose-0.98, we have been doing 
this already in the last weeks.

Naming, I am a bit reluctant to call the next release 1.0 unless we 
define clearly what 1.0 criteria we have, API stablity etc comes here to 
mind. Maybe we we can defer this by just calling the next release 
modestly 0.100.

Regards,
    Simon


[1] 
http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&group=owner&order=priority&col=id&col=summary&col=milestone&col=status&col=owner&col=type&col=priority&col=component&col=keywords&milestone=0.98&keywords=~regression
[2] 
http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&group=owner&order=priority&col=id&col=summary&col=milestone&col=status&col=owner&col=type&col=priority&col=component&col=keywords&milestone=0.98