On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote: > On Thursday 06 May 2010 02:14:44 am you wrote: > > On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote: > > ><snip> > > > > As current datastore and journal maintainer, some points: > > > > I'm still not sure will ml path proposal scheme work on not, it removes > > some bugs.sl.o issues but adds new e.g. it is pretty hard to collaborate > > (in my mind) via ml history, in case of bugs.sl.o, someone can just > > share http link to complicated query. Other thing is that on bugs.sl.o > > it is easy to query tickets by keywords for example. > > > > And since having patches both on bugs.sl.o and ml is pretty useless and > > there is no regular way to attach "0.90 targeted" keyword to ml posts, > > please create tickets on bugs.sl.o. > > Hi Aleksey. Thanks for taking the time to look at this. > > While I personally don't think it's that hard to collaborate on the ml, I > believe this discussion belongs in the "Code Review process changes" thread > [0]. Either way, the bug I referred to (#1915) contains the previous > discussion and links to both patchsets. It is also tagged as "r?", though no > one has taken a look at it yet. > > I should say that the fact that you commented on this thread before you did > so > on the ticket is evidence that reviewing patches here managed, at worst, to > grab the right person's attention, and at best will work the same for others. > > But I digress. I think your opinion is important and should be part of that > thread. > > > In case of journal, my strong thinking is that Journal shouldn't be only > > one for all purposes and it shouldn't be only in glucose as part of > > sugar core. I initiated journal library [3]. The major idea is that > > anyone can create his own journal activity and glucose can provide > > common/simple/default one. > > > > So, all my resources I spend to journal library (and related projects) > > not to journal code in glucose. If you share this thinking, please come > > aboard. > > I'm not convinced, but I could be. > > While I think opening up the API might encourage activity developers to > produce their own (potentially better) journal UI's, I feel it is a mistake > to > stop improving the canonical interface for accessing the user's data: it is > orthogonal; we can work on improving the current UI _and_ provide the tools > you mention.
Well, I was talking only from personal POV, having: * ugly gtk.TreeView usage in journal (lack of lazy model in gtk.TreeView) * need to integrate thumbs view For my own, I decided to concentrate all attention only on new journal library because fixing both mentioned code in step-by-step (when step it is glucose release) is pretty useless. New journal library inherited some model level code and has completely different UI part - field-widget based design and using HomogenTable list widget instead of gtk.TreeView. More over, I decided to create this library using only Polyol (w/o sugar-toolkit at all) to conform another my strong thinking [4]. So, all this work can't be done within glucose. [4] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Scalable_development_model > If you think Journal development should be halted until it is moved out of > glucose, we should get working on that; deployments need this feature. To be honest, I didn't think about it at all. I have only one simple idea, create more functional journal and give a chance to users to use it on 0.82+ sugars. With journal only in glucose, only 0.90 users will get features like thumbs view, with activity based scheme (since I'm planing to support 0.82+ in journal library) all users (keeping in mind that current stable OLPC release is 0.82, next stable will be 0.84) all of XO users will have a chance to use new journal like activities. Thus, in my mind, library journal is more important. > On the > other hand, the Journal was once an activity but was integrated into the > shell > in 0.84 (see commit f0ff3b) for performance and maintainability reasons, have > any of those priorities changed in your mind? In performance case, new library use the same model scheme (except minor improvements) thus performance will be the same. About other aspects of journal integration like security issues, my first intention was not create full functional replacement of current journal, only that could be done w/o close core integration. Creating full functional replacement will require shell dbus API improvements, I was planing to create ready-to-use first journal library based activity (Library-2) and only than propose appropriate shell dbus API features. > I've taken a look at some of the components of your Polyol project and I'm > impressed by the quality and quantity of your work, congrats!. > > > Having covered all the above, I thing only datastore patch is requested. > > You mean only the DS patch will be accepted? Sorry, I meant s/requested/required/, and of course I was talking from current journal maintainer POV. If there is someone who think that glucose journal should be improved in parallel w/ libjournal or that is wrong idea to base glucose Journal on libjournal, and have possibility to maintain glucose component, I'll pass my journal maintainanceship. Anyway, I think it would be good to split #1915 into two parts, ds and journal, at the end, these parts are independent, and two maintainers, datastore and journal, will have a chance to process only theirs parts of responsibility. > > > [3] http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal > > > > -- > > Aleksey > > > > [0] http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023410.html > -- > -Andrés -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
