On Tue, 14 Apr 2009 15:31:55 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> 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. nb - it does NOT solve all problems. it doesnt solve non-western languages (hcinese, korean, japanese, arabic, farsi, yiddish, hebrew, tamil, sanscrit, thai, ....). its a bad move. i removed vera from e's tree. it's not in elementary. i suggst removing it and just using "sans" - let fontconfig and the os font setup determine the font(s) used. these days sans and fontconfig are standard. > > * 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
