On Thu, 20 Oct 2011 15:55:58 +0200 Cedric BAIL <cedric.b...@free.fr> said:
> On Thu, Oct 20, 2011 at 10:41 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Thu, 20 Oct 2011 04:04:38 -0400 Mike Blumenkrantz <m...@zentific.com> > > said: > > > >> On Thu, 20 Oct 2011 15:51:01 +0900 > >> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > >> > >> > Hey guys. time to talk of our next release cycle. this meant 1.1 of most > >> > efl libs (and 1.5 for eet). this means we have lots of bug fixes and new > >> > features here. i'm currently talking about: > >> > > >> > eina > >> > evas > >> > ecore > >> > embryo > >> > edje > >> > efreet > >> > e_dbus > >> > eeze > >> > > >> > now coming AFTER this we want elementary to go 1.0 - so this is the last > >> > change we have to "break api's" in elementary. > >> > > >> > e17 itself is an app so api is "not relevant" here, but we also want to > >> > work full steam ahead on e17 release too. > >> > > >> > what i am proposing is that everyone finish their "pending work" for > >> > everything above in the first list and get all pending changes to elm > >> > upstream asap as well. i want to call a "2 week merge window" for core > >> > efl (above) and then 2 weeks of bug fixing, then release. merge window > >> > starts next monday (24th of october). that means from the 7th to the > >> > 20th no new features can be added to trunk, only bug fixes. > >> mmm this may be tough for eeze since supposedly users are having a lot of > >> trouble with eeze mounting in e17 and I can't reproduce their problems. It > >> would be great if I had some edevs working with me to test this so I can > >> get bugs out. > > > > i haven't spotted bugs of late... > > > >> > i am opening the floor to anyone who thinks other libraries in svn should > >> > also get the 1.0 treatment too - ethumb? epdf? emotion? > >> I could prep esskyuehl for a release if people think it would be useful to > >> have as a released library. I only have one or two trivial things to add, > >> and it has been otherwise unchanged since May/June. > > > > no - leave that. it's still in proto and it actually isn't used by any of > > e/efl elements currently, so no rush there. > > Agreed. We can't push library that don't have application using them > available to test them and their API. > > >> > some notes: eina will not have any eina-object model enabled for 1.1. > >> > evas will have all the evas-gl stuff disabled in build and install for > >> > 1.1 as its not stable yet. any more notes people have to throw in? > >> > > >> I think if we work on an elm release after 1.0 (which would be starting in > >> December?) it will be a big mistake. Elm right now is a giant clusterfuck, > >> so we should probably do the following instead of going straight for the > >> big 1.0: > >> * widget/feature freeze: NO MORE WIDGETS. PERIOD. there's too damn many > >> as it is and QA on them is terrible. > > > > well this is all part of 1.0 path. we can just ignore going 1.0 forever if u > > want and not do this... :) > > > >> * fix all existing widgets to work as intended: I say this in the general > >> sense as there are tons of widget api functions which do nothing, have > >> unintended side effects, or break the universe altogether. > > > > list please. (of api's not working(right)). > > > >> * review all existing widgets and apis: we may decide that some widgets > >> suck and should be removed. remember that anything we ship with 1.0 is a > >> widget that we have to support FOREVER. so, for example, this means that > >> diskselector (a TERRIBLE widget imo) is something that will need to be > >> maintained for years to come. it also means that widget features must be > >> maintained. if a widget has stupid features, they should be removed. > > > > list please. (widgets we shouldnt have). > > diskselector: actually api-wise its ok. it's IMPLEMENTATION is very much.. > > to be desired. this means we can release with it and fix its internals at a > > future point. > > > >> * finish all important TODO items for remaining widgets: there's tons of > >> these so I won't bother going into detail, but I think everyone can > >> think of at least a few items which belong here. > > > > i need to finish up some performance issues in elm_factory. > > > >> * merge similar widgets: anchorblock and anchorview are two separate > >> widgets which are essentially the same. why are they not one widget?? > > > > sure. they can be merged. or get rid of anchorview entirely. > > > >> * finish genlist/gengrid/factory merge: this has been talked about > >> forever, but it needs to actually get done. afterwards, genlist and gengrid > >> apis/internals need to be updated so that they match. > > > > no way is this ever going to happen any time soon. not for years. i‘d say. > > so its not worth getting worked up about. leave genlist/grid as is for now. > > I will disagree with you here. At least we need to make genlist and > gengrid API futur proof. Right now their interface can't evolve > without breaking the API or adding new function to instanciate new > object. We should at minima do what we did with Eet where we provide > both a version field inside the structure and a sizeof the structure > as a third parameter. At least that would give a chance to fix them > with time. I don't care much about the internal, but at least the > API/ABI should be clean to remain stable and working with time. > In fact this change should be done to all API that use structure > defined inside Elementary.h. well then you fix both genlist and gengrid. i give you 6 weeks. :) actually daniel was going to make a function to alloc item classes from genlist itself so it would be future-proof. > >> * rewrite MOST elm edc: if anyone has ever read through this, the > >> majority is pretty awful. additionally, we have great edje features now > >> like group inheritance which could cut down the size of the default theme > >> considerably. > > > > this is really an optional thing. but i'd actually like to revamp all of e17 > > +elm theme stuff anyway - but that'd push off being able to do releases by > > many months. > > Maybe just switching to detourious would be fine. A lot of work is > already done and it's good, maybe that's already your idea. i have considered that. it still doesn't negate me wanting to redo theme anyway. :) totally orthogonal things. > >> Looking at the scope of these items, I'd say it's at least a couple months' > >> work to get elm in the kind of shape necessary to consider even a basic api > >> freeze, after which point it will require even more time to fix bugs within > >> the freeze. > > > > reality is we need to freeze is much sooner than that. > > With the experience of last big freeze, for 1.0, I agree, it took us 4 > months to get to a state we liked for a release. Elementary is in my > opinion in the same state that were some EFL before we started the 1.0 > release cycle. Sooner we enter the freeze, more we can focus on the > cleanup/fixing of it. a freeze doesnt allow you to clean up api. it means its FROZEN. no deletions, changes OR additions. what i said was - get efl 1.1 out then focus on elm going to 1.0. thats precisely the same thing. i DIDNT say it will go 1.0 at the same time as efl 1.1 i said merge+freeze for CORE efl - elm is not in that yet. see i said "coming AFTER this..." :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
