On Mon, 23 May 2011 12:41:24 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> said:
> > > On Mon, 23 May 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Mon, 23 May 2011 12:12:35 +0200 (CEST) Vincent Torri > > <vto...@univ-evry.fr> said: > > > >> > >> > >> On Mon, 23 May 2011, Vincent Torri wrote: > >> > >>> > >>> > >>> On Mon, 23 May 2011, Carsten Haitzler (The Rasterman) wrote: > >>> > >>>> On Mon, 23 May 2011 11:05:04 +0200 (CEST) Vincent Torri > >>>> <vto...@univ-evry.fr> said: > >>>> > >>>> that requires i read the changelog and commit those patches - and it > >>>> takes time. as you said. > >>> > >>> A lot less than what cedric is doing right now > >> > >> to be precise : > >> > >> * you said that you didn't backport your fixes, and you would do the > >> backports later > >> * cedric is doing that works and it takes a LOT of time > > > > yes. i'd do it later. i havent done it yet. > > > >> What I want is that, for the future fixes that you will do and for those > >> who need a backport, you immediatly do the backport. That way is faster > >> that what cedric is doing. > > > > actually it isn't. :) its the exact same work. > > No : for example, I don't need to read the changelog : i know i have to > put it at the end. So it's faster. What I do when i backport immediatly: > > * i change the code > * i append the changelog message at the end > * i create a diff > * i apply it in the branch > * i commit both changes > > what cedric has to do when the backport is not done : > > he read the changelog, he must verify that the comit is actually something > to backport. He has to get the diff, apply it to the branch and update the > changelog and commit. That takes a lot more time than doing the backport > immediatly. a commit when backported immediately runs the risk also of having to be updated again and backported again a day later and again and again as the 1 fix evolves. there is nothing i can do right now that makes any of this easier or simpler. > > > >> Vincent > >> > >>> > >>> Vincent > >>> > >>>> > >>>>> On Mon, 23 May 2011, Enlightenment SVN wrote: > >>>>> > >>>>>> Log: > >>>>>> ecore: backport r58033. > >>>>> > >>>>> it takes more time to read the changelog and see which commit has to be > >>>>> backported than backported immediatly > >>>>> > >>>>> Raster, can you please backport immediatly your commits (if necessary) ? > >>>>> > >>>>> Vincent > >>>>> > >>>>>> > >>>>>> > >>>>>> Author: cedric > >>>>>> Date: 2011-05-23 01:54:49 -0700 (Mon, 23 May 2011) > >>>>>> New Revision: 59612 > >>>>>> Trac: http://trac.enlightenment.org/e/changeset/59612 > >>>>>> > >>>>>> Modified: > >>>>>> branches/ecore-1.0/ChangeLog > >>>>>> branches/ecore-1.0/src/lib/ecore_evas/ecore_evas_util.c > >>>>>> > >>>>>> Modified: branches/ecore-1.0/ChangeLog > >>>>>> =================================================================== > >>>>>> --- branches/ecore-1.0/ChangeLog 2011-05-23 07:51:44 UTC (rev > >>>>>> 59611) +++ branches/ecore-1.0/ChangeLog 2011-05-23 08:54:49 UTC > >>>>>> (rev 59612) @@ -30,3 +30,8 @@ > >>>>>> > >>>>>> * Fix: ecore_con_url_ftp_upload upload the file until the end. > >>>>>> > >>>>>> +2011-03-23 Carsten Haitzler (The Rasterman) > >>>>>> + > >>>>>> + * Fix: ecore-evas interceptor didn't handle override-redirect > >>>>>> + windows correctly, expecting a feed-back event from x, which > >>>>>> it didn't > >>>>>> + get. > >>>>>> > >>>>>> Modified: branches/ecore-1.0/src/lib/ecore_evas/ecore_evas_util.c > >>>>>> =================================================================== > >>>>>> --- branches/ecore-1.0/src/lib/ecore_evas/ecore_evas_util.c > >>>>>> 2011-05-23 07:51:44 UTC (rev 59611) +++ > >>>>>> branches/ecore-1.0/src/lib/ecore_evas/ecore_evas_util.c > >>>>>> 2011-05-23 08:54:49 UTC (rev 59612) @@ -57,11 +57,12 @@ /* > >>>>>> Interceptors Callbacks */ > >>>>>> > >>>>>> static void > >>>>>> -_ecore_evas_obj_intercept_move(void *data, Evas_Object *obj > >>>>>> __UNUSED__, Evas_Coord x, Evas_Coord y) +_ecore_evas_obj_intercept_move > >>>>>> (void *data, Evas_Object *obj, Evas_Coord x, Evas_Coord y) { > >>>>>> Ecore_Evas *ee = data; > >>>>>> // FIXME: account for frame > >>>>>> ecore_evas_move(ee, x, y); > >>>>>> + if (ecore_evas_override_get(ee)) evas_object_move(obj, x, y); > >>>>>> } > >>>>>> > >>>>>> static void > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------------------------ > >>>>>> What Every C/C++ and Fortran developer Should Know! > >>>>>> Read this article and learn how Intel has extended the reach of its > >>>>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran > >>>>>> developers boost performance applications - including clusters. > >>>>>> http://p.sf.net/sfu/intel-dev2devmay > >>>>>> _______________________________________________ > >>>>>> enlightenment-svn mailing list > >>>>>> enlightenment-...@lists.sourceforge.net > >>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > >>>>>> > >>>>>> > >>>>> > >>>>> ------------------------------------------------------------------------------ > >>>>> What Every C/C++ and Fortran developer Should Know! > >>>>> Read this article and learn how Intel has extended the reach of its > >>>>> next-generation tools to help Windows* and Linux* C/C++ and Fortran > >>>>> developers boost performance applications - including clusters. > >>>>> http://p.sf.net/sfu/intel-dev2devmay > >>>>> _______________________________________________ > >>>>> enlightenment-devel mailing list > >>>>> enlightenment-devel@lists.sourceforge.net > >>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>>>> > >>>> > >>>> > >>>> -- > >>>> ------------- Codito, ergo sum - "I code, therefore I am" -------------- > >>>> The Rasterman (Carsten Haitzler) ras...@rasterman.com > >>>> > >>>> > >>> > >>> ------------------------------------------------------------------------------ > >>> What Every C/C++ and Fortran developer Should Know! > >>> Read this article and learn how Intel has extended the reach of its > >>> next-generation tools to help Windows* and Linux* C/C++ and Fortran > >>> developers boost performance applications - including clusters. > >>> http://p.sf.net/sfu/intel-dev2devmay > >>> _______________________________________________ > >>> enlightenment-devel mailing list > >>> enlightenment-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > >>> > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
