Re: [E-devel] Community Building - release
Toma wrote: 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
Re: [E-devel] Community Building - release
I wrote: ... 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 I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) 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? Click for FHA loan, $0 lender fees, low rates approvals nationwide http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mItjHT46zg0b4UPUAGi6dZfbcr8x5PmjR6BgYgXGZVlZkta/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On 31/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: ... 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 I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) Yes... I mean ask the general random normal desktop users that wander into #e on freenode and ask those kind of questions. After all, theyre the ones that want to use E17. I think developers tend to think like developers and dont tend to see the importance of mundane little things that the average Joe likes/wants. Thats why companies employ market researchers to see whats needed and wanted. Im not saying E needs anyone dedicated to market research, but its something to keep in mind. Personally, I made a couple black themes then people said You should try making a light theme, so I made Edjy and Cerium. Thats an exmaple of listening to the 'market'. Having said that, I see alot of enthusiasm on random tech forums for EFL and you could see the reaction on the aMSN forums when you compared EFL directly to EFL. People scrambled to get EFL installed and were really impressed by how it looked. The biggest problem everyone had (including myself) was building the libraries needed, and I dare say would have been a lot easier if there was a packages release of EFL-Python and all its deps. So maybe a more steady snapshot schedule and perhaps a couple days of *Bug Extermination* before those snapshots so developers and users a like can access it all a little easier? 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? Click for FHA loan, $0 lender fees, low rates approvals nationwide http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mItjHT46zg0b4UPUAGi6dZfbcr8x5PmjR6BgYgXGZVlZkta/ - 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
Re: [E-devel] Community Building - release
Toma wrote: On 31/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: ... 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 I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) Yes... I mean ask the general random normal desktop users that wander into #e on freenode and ask those kind of questions. After all, theyre the ones that want to use E17. I think developers tend to think like developers and dont tend to see the importance of mundane little things that the average Joe likes/wants. Thats why companies employ market researchers to see whats needed and wanted. Im not saying E needs anyone dedicated to market research, but its something to keep in mind. Personally, I made a couple black themes then people said You should try making a light theme, so I made Edjy and Cerium. Thats an exmaple of listening to the 'market'. Ok, sure. But in the case of developers that are building things like a gfx lib or a gui toolkit, then their market might be other developers, not directly end-users-of-some-app. Having said that, I see alot of enthusiasm on random tech forums for EFL and you could see the reaction on the aMSN forums when you compared EFL directly to EFL. People scrambled to get EFL installed Errr.. I'm not sure I follow you here, but I guess this is a good thing? and were really impressed by how it looked. The biggest problem everyone had (including myself) was building the libraries needed, and I dare say would have been a lot easier if there was a packages release of EFL-Python and all its deps. So maybe a more steady snapshot schedule and perhaps a couple days of *Bug Extermination* before those snapshots so developers and users a like can access it all a little easier? Toma Maybe what you're trying to get at here is the issue of releasing the libs that Vincent and Nathan pointed to, or some of them, and e17 as well. I personally don't think evas, ecore, edje are ready for 'release' in the sense of them being so stable that further near-future changes wouldn't break anything. Not near really. However, that doesn't mean they couldn't be released as they are, and leave such changes for a future version of those libs. But then I'm not the maintainer(s) of those libs, and they may disagree with me. Click here to compare top medical billing products, get demos, and quotes. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oiDnLrNIJc6ZgQsiMlLjmRfs5Jv0LVqHgkFX1bBsUVYSgtx/ - This SF.Net email is sponsored by the
Re: [E-devel] Community Building - release
I wrote: Toma wrote: On 31/07/2008, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: ... 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 I'm not sure I follow some of this. There are many different things that E could do or become, it's not just a question of what the wm/desktop-shell could do/be, or even what a desktop environment of some sort could do/be. There are questions of development 'platforms', what they might be geared to develop, what they might emphasize, and such... and there are questions of what kinds of apps or further libs or frameworks people might want to build beyond that, to create some sort of coherent 'environment(s)' and such. If you're going to ask people, then it depends who these people are and what kind of audience they are: end-users of apps? end-users of desktop environments/shells/whatnot? theme designers (of what)? developers of apps? rich app developers? etc. Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all E developers. :) Yes... I mean ask the general random normal desktop users that wander into #e on freenode and ask those kind of questions. After all, theyre the ones that want to use E17. I think developers tend to think like developers and dont tend to see the importance of mundane little things that the average Joe likes/wants. Thats why companies employ market researchers to see whats needed and wanted. Im not saying E needs anyone dedicated to market research, but its something to keep in mind. Personally, I made a couple black themes then people said You should try making a light theme, so I made Edjy and Cerium. Thats an exmaple of listening to the 'market'. Ok, sure. But in the case of developers that are building things like a gfx lib or a gui toolkit, then their market might be other developers, not directly end-users-of-some-app. Having said that, I see alot of enthusiasm on random tech forums for EFL and you could see the reaction on the aMSN forums when you compared EFL directly to EFL. People scrambled to get EFL installed Errr.. I'm not sure I follow you here, but I guess this is a good thing? and were really impressed by how it looked. The biggest problem everyone had (including myself) was building the libraries needed, and I dare say would have been a lot easier if there was a packages release of EFL-Python and all its deps. So maybe a more steady snapshot schedule and perhaps a couple days of *Bug Extermination* before those snapshots so developers and users a like can access it all a little easier? Toma Maybe what you're trying to get at here is the issue of releasing the libs that Vincent and Nathan pointed to, or some of them, and e17 as well. I personally don't think evas, ecore, edje are ready for 'release' in the sense of them being so stable that further near-future changes wouldn't break anything. Not near really. However, that doesn't mean they couldn't be released as they are, and leave such changes for a future version of those libs. But then I'm not the maintainer(s) of those libs, and they may disagree with me. By a future version of those libs of course I meant a 'major' version increase. In any case, if you want to know why I don't think eg. evas is near ready for a release: it's not just gradients or vgfx stuff,
Re: [E-devel] Community Building - release
By a future version of those libs of course I meant a 'major' version increase. In any case, if you want to know why I don't think eg. evas is near ready for a release: it's not just gradients or vgfx stuff, it's possibly smart classes and native surfaces that may need breaking changes, it's the soft16 engines which are really not ready for use (need to be replaced), it's the fact that having evas data structures does nothing good for E (I believe they need to be moved out of evas and have evas depend on that lib - eina or edata or whatever), and a few other things. There is also the option of releasing things as a pre-alpha test version, and see what the reaction is, and work from there. that's a bit what i propose when i said to release as 0.10. We keep the major release to 0 and are free to break anything for the major 1 version In addition, packagers will be happier with a 0.10 release rather than with a snapshot, which means that we can spread the efl technologies in a better way than what is currently done. Vincent - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
that's a bit what i propose when i said to release as 0.10. We keep the major release to 0 and are free to break anything for the major 1 version In addition, packagers will be happier with a 0.10 release rather than with a snapshot, which means that we can spread the efl technologies in a better way than what is currently done. Vincent I agree with you. I follow E mailing list and irc discussions for 3 or 4 years now. I begin to code with EFL for 3 years. I use core EFL evas, ecore, eet and edje not intensively as some of you do, but what I have seen in this 4 years, it's that they have been only few API breaks. My first little EFL program runs and compiles today. If I'm not mistaken the biggest changes that have been done is evas_list (evas_list_goto_first/evas_list_first_goto) and ine evas_smart or things like that. I'm speaking about API not the core. In an other hand, my first EFL application run faster than 3 years ago, very very faster. Evry day day evas_test and now expedite run faster on the same PC. I can run EFL on N810, it's very fast too. I can experiment on Windows Mobile and Windows Vista. It's awesome ! When I read RFC on mailing list, I see only new api, and no api break. Maybe I'm mistaken, but if we wait longer before a release (EFL libs not E) community envolved in this project will decrease. I think that a pre reslease like Vincent say, is a good choice for the future of this project. EFL are very good, it's realy a pleasure to work and play with this libs, but unfortunately this not the technical stuff that people are watching but rather the stability, the number of users, and the time they could win using this libs. I think, with my external point of view, that EFL are (for a long time now) closed to be release. Maybe we should follow this TODO list, if we have a goal and a dead line, we should work faster and better. If a release (or pre release 0.10) is done, we will have more developpers that could looks at this libs for their future developments. Community will have more motivation to write doc, examples and program that use EFL. It should be better for evryone. But maybe it's not your goal ? I don't blame anyone, It's just the thoughts of a guy that follow mailing list discussions for some time now. Regards, Nico - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
Toma escreveu: 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? As a end-user, I think the foundations need to be solid. What happens if I drag icons around to and from things, does it does something useful? One of my major concerns when moving between DE's is that I always want some way to build quick access to the common apps of my everyday use and some break apart when doing that. It doesn't need to be icons on desktop, not event show icons at all, as long as the function to do so is there and works. Another one is a fast filemanager that works in what it tries to do. Even minimalist ones like the one included in xfce would suffice, as long as it works. It seems even kde is looking for less features-more simplicity... I didn't tried e17 for a long time, so I cant' say what's the problem today (if there is one), I may be willing to again at home, at work is just hard to get the time to do so. My $ 0.02 Solerman - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: 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. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. Bruno - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On 31-Jul-08, at 3:48 PM, Bruno wrote: On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: 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. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. http://bugs.enlightenment.org/ http://trac.enlightenment.org/e dan - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On Thu, 31 July 2008 dan sinclair [EMAIL PROTECTED] wrote: On 31-Jul-08, at 3:48 PM, Bruno wrote: On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: 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. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. http://bugs.enlightenment.org/ http://trac.enlightenment.org/e Unfortunately these list only wishlist/todo parts. It would also be good to at least get them more visible in the context of E17 on www.enlightenment.org Bruno - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On 31-Jul-08, at 4:14 PM, Bruno wrote: On Thu, 31 July 2008 dan sinclair [EMAIL PROTECTED] wrote: On 31-Jul-08, at 3:48 PM, Bruno wrote: On Thu, 31 July 2008 Toma [EMAIL PROTECTED] wrote: 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. Related to what people might wish, it would be good as well to have some feature-list on the website, list which would be split in 3 parts: - implemented/complete features - features being worked on - wish/todo list Where possible this information should be categorized for the different parts of Enlightenment (E itself and its modules - some modules probably separately, the various libraries, applications around E like efm, epdf, ...) This would make it easier to know what E can do, if one's own needs are fulfilled and what's missing. Also it gets a better incentive to try and fill some of the gaps or even just try out Enlightement. http://bugs.enlightenment.org/ http://trac.enlightenment.org/e Unfortunately these list only wishlist/todo parts. It would also be good to at least get them more visible in the context of E17 on www.enlightenment.org Depends on if the projects are using it. You can see features we're working for Ewl and the discussions we've had about how to implement them. You can also search for resolved and closed bugs to see what's implemented and complete. dan - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
On Thu, Jul 31, 2008 at 3:24 PM, dan sinclair [EMAIL PROTECTED] wrote: Depends on if the projects are using it. You can see features we're working for Ewl and the discussions we've had about how to implement them. You can also search for resolved and closed bugs to see what's implemented and complete. dan We also set the release target, so you can tell what features/fixes are required for that release to come out. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
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
Re: [E-devel] Community Building - release
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 This message was sent using IMP, the Internet Messaging Program. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
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
