On 03/26/2013 01:20 PM, Walter Bender wrote:
On Tue, Mar 26, 2013 at 8:07 AM, Daniel Narvaez <dwnarv...@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@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
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
