Vincent wrote:
> Quoting Nathan Ingersoll <[EMAIL PROTECTED]>:
>
>> One idea I discussed with Vincent today is that our lack of releases
>> has caused many users to lose interest and stop taking notice of the
>> project. I realize that there is a lot of talk surrounding changes to
>> core infrastructure (data lib, graphics, scripting language, etc), but
>> has there been any thought recently put into how our release process
>> should be structured? There used to be a TODO list for e17, and that
>> has been moved to Trac, but has anyone took a hard look at what is
>> necessary for cutting a stable release? Even if we don't release e17
>> 1.0, we may be able to move the core libs towards releases like eet.
>>
>
> Some ideas I and others have:
>
> 1) We must release the core libs (evas, ecore, embryo, edje, efreet and
> e_dbus,
> that is what is needed by e17). So we must discuss to what must be done for
> each of them before a release. Here what I think. You can add other things I
> have forgotten.
>
> * embryo: is in a very good shape. raster wanted to release it later
> because he
> wants to look at lua for scripting. I think that it is a very bad idea, and
> should be delayed for the next version. What may lack is documentation.
>
> * evas: also in a very good shape, but several things wanted to be done: api
> changes in polygons, gradient and data types (see below). Documentation
> must be
> improved too. Although polygons can be done in a rather short amount of time,
> gradient stuff can take a long time and maybe can be done (with other things
> like vgfx) in the next evas major release. Note that Nathan and me agreed on
> the fact that, today, we should have an evas 3.*, and not 0.9...
>
> * ecore: Cedric wants to reorganize some stuff in ecore_evas. Also data types.
> See next point
>
> * evas and ecore: data types. The problem is that it will break abi if we
> change the data types. See below for a "solution"
>
> * edje: except the problem of data types, I don't see any major flaw.
>
> * efreet and e_dbus: I don't know much about them. They are used with e17
> without problem. Cedric told me that he wanted to speed up efreet.
> There is the
> problem of data types, though.
>
> The problem with data types is that it will break ABI and API. So we
> must decide
> if we release with or without the change in data types.
>
> A solution is to "release" with number version 0.10 (current version number is
> 0.9.9) without data type changes and warns that there will be big changes for
> 1.0.
>
> 2) A release manager must be named. What he should do:
>
> * decide which library may be released because of a certain amount of
> important
> bugs have been fixed. Of course, this should be discussed in the ML for
> example.
>
> * sent mails to warn about pre-releases (in that period, only bug fixes
> and doc
> changes are allowed. Maybe other things i can't think of.) and releases
>
> * of course, provide the tar balls for pre-releases and releases
>
> * maybe add news on some sites like osnews, /., freshmeat or phoronix
>
>
> Even if there are 0.10 releases before a 1.0, the fact that we announce such
> release is a good thing. As an example, Kim is doing e16 releases
> periodically.
> Each time one is done, a user announce that on osnews. And i often read
> in those
> news that people are happy to see that e16 is still maintained.
>
> Comments, ideas ?
>
> Vincent
>
It's good to see such attempts and I hope they continue. I'd also like to
applaud Carsten for taking the high-road, and I hope that E can become a more
inclusive project able to honestly embrace differences, attract developers, and
work with others.
As to the above mentioned steps.. I disagree with some of the arguments,
but they are also not unreasonable - so long as everyone realizes that the state
of many things in E is still rather basic and are willing to 'break' apis on
major releases when they bring good improvements.. E is still small enough that
it can be fluid if it wants to.
But, one very important thing to consider here is: What exactly is it that
E wants to achieve? What are the basic 'large' goals?
If all that's really wanted is a wm/shell kind of thing, then you've got
it.
It's pretty good - could be better, etc. - but it's there.
If some want 'development platforms' then what kinds? And which
apis/models
are best suited to build whatever with? Which can be attractive to certain areas
more than others, etc.
If some want to also build environments/whatnot on top of those platforms,
then what apps/libs do you need for short, mid, long term growth?
What are relevant models out there in open, partly-open, not-so-open
worlds,
that could be used for comparison?
____________________________________________________________
Are you safe? Click for quotes on a home security system.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3ni3cmhqo7KpaXBvOXjVp9YlEZ01MorJ1KlpuJpLIAiD7Ig3/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
