[Sugar-devel] Next release
walter.bender at gmail.com
Tue Mar 26 08:20:57 EDT 2013
On Tue, Mar 26, 2013 at 8:07 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
> 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
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
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
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 .
 http://wiki.sugarlabs.org/go/1.0/Roadmap (just a stub)
More information about the Sugar-devel