[Sugar-devel] [SWEETS] glucose-0.92 via sweets
Aleksey Lim
alsroot at activitycentral.org
Sat Jul 16 14:56:31 EDT 2011
On Sat, Jul 16, 2011 at 01:36:32PM +0100, Daniel Drake wrote:
> On 16 July 2011 12:50, Aleksey Lim <alsroot at activitycentral.org> wrote:
> > All of them on bugs.sl.o, since I'm not maintaing collab code and it was rewritten in 0.9x
> > (and never worked fine since then for me), plus jabber.sl.o has bunch of noise trafic,
> > I, w/ tweaking prosody patch, patched client code as well. ie, final
> > implementaion might be too different. thats why these patches are on
> > bugs.sl.o.
>
> I'd suggest that you submit them as patches to the mailing list -
> thats the current community norm, even if you aren't a maintainer, and
> will form the discussions that would help turn them into a final
> implementation.
You got me wrong, dunno for others but I'm prefering working in two
modes, patching stable code (and emailing to sugar-devel@) and devepping
new features (and do not email every commit to ML).
In my mind new collab code was never stable but unfortunately
committed to the trunk. In that case I was very surprised when tried recent
0.92, that OLPC is going release these days, and found bunch of critical issues
(and got assumption that if olpc is ok w/ that, they patched ejabberd,
which is abs. wrong way for me).
Personally, if I would glucose maintainer (but I'm not), I will fallback to PS
and form new collab code as a feature w/ people who will work in
development mode (ie, not sending every commit to ML) and make it stable
(being assured by tests). Then, it might replace PS.
Thats my personal vision on new collab feature. To move forward, and have it
in 0.92 if people want, we need not maintainers (and every commit
reviewers/accepters on ML) but collab developers who will work in
development mode to revisit and understand(since we don't have original
feature developer) the entirely implementation.
>
> Thanks for your work.
> Daniel
>
--
Aleksey
More information about the Sugar-devel
mailing list