Re: [E-devel] the release schedule targets

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Tue, 14 Apr 2009 15:31:55 -0300 Gustavo Sverzut Barbieri
<bar...@pr...> said:

> On Mon, Apr 13, 2009 at 7:00 PM, sda <dmi...@gm...> 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: bar...@gm...
> 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...