On Fri, May 7, 2010 at 11:05, Aleksey Lim <alsr...@member.fsf.org> wrote: > 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.
I'm worried about how this could affect deployments negatively, but as we don't have a forum for developers to discuss these subjects with them... IMHO, you as a maintainer shouldn't take such a decision without making at least some efforts to make sure you aren't jeopardizing the ability of downstreams to pick up future versions of Sugar. I know it's very hard right now for developers like you to get that feedback, but unfortunately there doesn't seem to be enough interest to create a deployment team where these questions could be brought... Regards, Tomeu >> 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 > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel