On 30/07/2008, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > 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? >
Thats a funny one, because a lot of people say "Oh, E17 isnt as good as Gnome... or KDE" when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask people, what 'needs' to be done? I see a few people on IRC and on forums saying, "E17 is good, but its just not finished/has bits missing". Some lusers go as far to say "Err E17 is buggy and not stable! Waa" simply becuase there isnt a 1.0 release. Toma > 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 > ------------------------------------------------------------------------- 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
