* Mike Blumenkrantz <m...@zentific.com> [2011-10-20 04:04:38 -0400]: > 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 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. > > > > 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. > * 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. > * 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. > * 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. > * merge similar widgets: anchorblock and anchorview are two separate widgets > which are essentially the same. why are they not one widget?? > * 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. > * 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. > > 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.
Totally agree, here. The toggle->check merge is just the point of the iceberg in what needs to be done towards an elegant, minimal set of widgets in elm. The broken widgets are also a big issue, indeed. > -- > Mike Blumenkrantz > Zentific: Doctor recommended, mother approved. > > ------------------------------------------------------------------------------ > 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 -- Gustavo Lima Chaves Computer Engineer @ ProFUSION Embedded Systems ------------------------------------------------------------------------------ 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
