On Mon, Apr 13, 2009 at 7:00 PM, sda <[email protected]> wrote: > hi guys, > > beg your pardon for the disturbing and deepest apologizes if i miss the > existing official statements already published (if any). > > assume that following guidelines are a base for the subj: > http://trac.enlightenment.org/e/wiki/Release > http://trac.enlightenment.org/e/wiki/ReleaseSchedule > > wish to have the detailed list of packages for our release of E-DR-17. > this e-mail also seeks other "Enlightenment" packagers to set the common > packaging rules and provide similar builds for the Users. this could > help us to trace various issues (if any) and provide "E" as it should be > (instead of "it goes like it is"). > > as a maintainer of E-svn current repo glad to list some patches we > offer to the Users (openSUSE): > > * replacement (in sources before compilation) all Vera fonts to DejaVu > (this solves all issues with UTF-8 "native" locales)
IMHO we can replace them in SVN and actually remove all .ttf files, leaving it just for fontconfig as much as possible. Maybe expedite should stay to make it more reliable. > * global update of the repo (all packages are build from a single E-svn > revision source) this is the idea, I'll commit a file FEATURE-LOCK on Thursday night and remove it on Sunday night (or Monday morning), you can use the revision i use to remove the file as the one to be used. > * proper configuration of a "places" module (only for SOAD users as this > action break default security presets of openSUSE) default set of options as well as wizard pages to use are up to packagers, but if you can manage to provide an uniform experience it would be good. > and so on. also we're not providing (yet) the support for DirectFB > engine and the content of our repo definitely could be improved: > http://download.opensuse.org/repositories/home:/dmitry_serpokryl:/Enlightenment-cvs-core-metapackage/openSUSE_11.1/ Do not ship DirectFB, its not of much help in the current state. It's most useful for corner cases like set-top boxes, so leave it out. BTW, ecore-evas is really bad at it. While evas is all nice an dynamically loads modules, ecore-evas is very bad and links to all libs, so you end loading SDL even if you never use it. So be conservative with the number of modules you link. Maybe we should add this as a TODO for Ecore-Evas 1.0? > wish to have some "standards" for "E" packages like: > > 1) list of a "must have" packages (quantity really doesn't matter much) I'd say systray, places, tclock and notification because i use them and seems ok. (Actually I use bling, but it's not something stable or that I would recommend). I'd make these enabled by default. My plan is to move systray in e/src/modules soon. I'd NOT provide things like weather/forecasts or others that are known to break E17 randomly (one of these two always screw my system). harmless eye candy like penguins, flames, rain are also ok, but leave them disabled by default. > 2) list of a "features to be supported" (here goes "quality" - like > support of the following image formats: blah-blah..., following "engines", > "modules" and so on) E could ship with all modules enabled by default at compile time. So far I just disabled "connman", but maybe we want to disable others like conf_colors? Raster? > 3) proper indication of E-svn revisions to be build in our repos (as it > proposed by k-s) > > 4) any other suggestions from E-devs none > just as an option (in doubt that it'd be a benefit but...): > after each update/upgrade i can easily prepare a kind of "development" > system images (LiveCD + USB) packed with dev tools (list your favorites > here please) and not stripped binaries + devel headers. couldn't you provide the stripped debug symbols in /usr/lib/debug as separate package (-dbg)? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
