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. >> * 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. >> 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. -- Cedric BAIL ------------------------------------------------------------------------------ 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
