Re: [E-devel] Release schedule and request for help
2009/6/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, If you follow http://trac.enlightenment.org/e/wiki/Release you will notice that more and more items are being strike out in the past months due work of many individuals, we'd like to thank them all. Among contributors we can even find out nice examples like Luca De Marini that is not a programmer but fund/help the work of Sergey P. Semernin to help finish that list. http://local.profusion.mobi:8081/~lfelipe/output-efl seems to be dead . my 2 cents :) -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://www.digital-corner.org -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule and request for help
On Wed, Jun 10, 2009 at 10:03 AM, Nicolas Aguirreaguirre.nico...@gmail.com wrote: 2009/6/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, If you follow http://trac.enlightenment.org/e/wiki/Release you will notice that more and more items are being strike out in the past months due work of many individuals, we'd like to thank them all. Among contributors we can even find out nice examples like Luca De Marini that is not a programmer but fund/help the work of Sergey P. Semernin to help finish that list. http://local.profusion.mobi:8081/~lfelipe/output-efl seems to be dead . my 2 cents :) It shouldn't be, perhaps it was just some temporary issue. I'm still trying to keep it as up to date as possible (and I'm keeping the first one there as well just for historical purposes :P). --lf -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://www.digital-corner.org -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Sometimes you gotta look reality in the face and say no! -- Benjamin Gonzalez -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule and request for help
2009/6/10 Luis Felipe Strano Moraes luis.str...@gmail.com: http://local.profusion.mobi:8081/~lfelipe/output-efl seems to be dead . my 2 cents :) It shouldn't be, perhaps it was just some temporary issue. I'm still trying to keep it as up to date as possible (and I'm keeping the first one there as well just for historical purposes :P). Ok my bad, at work we have a proxy that refuse to connect on 8081 port. It works fine at home sorry :) -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://www.digital-corner.org -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule and request for help
On Tue, Jun 9, 2009 at 1:17 PM, t...@hiddenrock.com wrote: If you are willing to help but have no deep knowledge of the project, we can aid you with such tasks. Lots of them just require basic C skills, like converting Ecore/Evas data types usage to Eina (in Ecore, E_DBus, efreet, ...). This is me. Where can I start? (I have some experience writing Evas/Edje apps, but my depth is limited to the APIs, not the internals.) Hi Tam, I just replied to the other user who wants to help, the data type conversion is a good thing for you too. Just mail the list with your take and start to move that project to new types! :-) After that you all should get used to EFL and coding style, how to develop and we can get you on other tasks, probably fun tasks after then :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, 8 Apr 2009 12:29:50 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: ok. looking here the problme is.. you have a schedule.. that has none of the following: a knowledge of how long tasks will take people available to do the tasks time guaranteed from all the people this schedule doesn't account for any of that. the result will be a date rolls around with none of the stuff done for it. i propose something MUCH simpler. if the aim is stability in stages maybe simply call freeze dates. you have until 30th april to finish your current work, if it's underway. anything not done by then must be disabled/removed/unpatched. work can happen as long as it is compile-time enabled or runtime enabled and has no effect unless enabled. then within a few days of that date tarballs are produced with incremented release numbers. how about that? :) Hello all, As you might know we have to do the following list in order to release: http://trac.enlightenment.org/e/wiki/Release But until then we'll have a long time and it's bad to not have intermediate releases to help users try enlightenment and its libraries. So talking to lots of packagers and distros we know they want to include our code, but they need us to have something good enough to be packaged, so they will not be caught into eina-transition breakage or so. So we talked a bit at IRC and I wrote the following schedule that we'll try to accomplish: http://trac.enlightenment.org/e/wiki/ReleaseSchedule Dates there are not hard, it's just my initial suggestion. If you have suggestions, please say so now. After first alpha we can discuss beta and final release dates, later on we should enter a 3-6 months releases, no matter what. Before replying to this thread, please READ the wiki. The freeze is not a FEATURE FREEZE, or IDEA freeze, or nothing. We do not have to do some tasks before it, neither we are not allowed to do tasks before it - everyone is free to choose in what to work (but please give the Release plan higher priority!). We are just FREEZING NEW FEATURES SVN COMMITS IN TRUNK. And it's just for a weekend, so should be harmless. But we do expect that on Monday after freezes the packagers can create usable packages. Developers also requests that packagers participate more into the process and try to share efforts. We have lots of different .deb repositories and one does not seem to talk to the other. When you plan to do packages, ask at IRC and here if the state of the trunk is good and report problems. Now we also have that page that should describe good dates to get the code. Last but not least, we need help testing! If you are an user, please use http://trac.enlightenment.org/e/wiki/TestingPlan read it and add information to it (it's very barebones now), create tickets at our trac and let us know of problems. Since developers will not be able to create new code during freezes, they'll be left looking at tickets and fixing them :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Fri, Apr 10, 2009 at 7:57 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Thu, Apr 9, 2009 at 8:45 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Apr 9, 2009 at 2:29 PM, Luca De Marini luca.darkmas...@gmail.com wrote: 2009/4/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi and please, let's try to get these things upstream into debian, ubuntu and others. At least the base libraries and e17 itself. Of course. We will be in upstream, I'm sure of it, when we'll be stable. For Ubuntu at least. I don't know debian policies but Ubuntu won't host officially our E17 packages unless they are stable. So, whenever libraries will become stable, we'll be able to ask Ubuntu to host them in their officla repos and time by time, the entire E will hopefully be in Ubuntu :) Don't worry, we'll strictly collaborate, if you wish, to transform this into reality. often we become unstable, with things like moving ecore/evas to eina data types and major refactors, but other than that it works, maybe better than most software that is labeled as stable. Also, it is not true that everything in Ubuntu/Debian is stable and all, you can see how many packages break now and then, how many request you to export weird -DI_KNOW_THIS_IS_UNSTABLE_API and all. They break the interfaces at a slower pace, though :) That's IMO the sole reason for e17 not being in ubuntu: it's hard to push it to a stable release knowing that you'll have to support it for a long time, during which at least half a dozen API changes will happen. Otherwise, I would have uploaded the whole stack in ubuntu a long time ago (and as said on IRC, I plan on uploading what's currently in debian experimental to ubuntu when it's possible) i disagree here, it's just a matter of uploading them. DBus went in Ubuntu it was much more unstable yet it was deemed as core component. E17 is not core and basic the leaf of a system, if it does not work, nothing but it is affected (and its users, of course - but these are either experienced users that know e17 and are just not bothering to compile it or newbies that will try and go back to something else later). As for the schedule, I think it's better no to plan on the packagers being able to deliver packages within a day. You probably know there are a lot of packaging rules (even if the SVN packaging doesn't really care about them, as it would be a pain, like packages renaming when there's an interface break and so on), and updating the packages may take time. I think we could just skip the first build, that will give some more time. the dates there are mostly for developers, packagers are suggested to act at that time, but if not, just get a revision around that time and do it later. I plan to commit FEATURES-LOCK in /trunk and remove it when freeze is over, you can use those revision numbers to generate it. We're not a company with obligations, rather a community with good will to do things, so no way to force packagers to generate packages at midnight UTC, but if you want to use a script, then you can crond/atd and be happy. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Fri, Apr 10, 2009 at 11:14 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 8 Apr 2009 12:29:50 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: ok. looking here the problme is.. you have a schedule.. that has none of the following: a knowledge of how long tasks will take people available to do the tasks time guaranteed from all the people this schedule doesn't account for any of that. the result will be a date rolls around with none of the stuff done for it. i propose something MUCH simpler. if the aim is stability in stages maybe simply call freeze dates. you have until 30th april to finish your current work, if it's underway. anything not done by then must be disabled/removed/unpatched. work can happen as long as it is compile-time enabled or runtime enabled and has no effect unless enabled. then within a few days of that date tarballs are produced with incremented release numbers. how about that? :) well, maybe i'm too bad at explaining stuff, but my suggestion was exactly that. I don't want to block developers, that's why it is a weekend. But it would be good to ask developers to help test and fix bugs whenever possible. And I tried to put dates that would not bring problems with GSoC since most developers are also mentors or students, and also because it's good to know beforehand when it will happen. I already have my schedule in Google Calendar, I plan to mail the list on Monday with a warning about freeze on Thursday, then one on Thursday and then another on Sunday. Let's see how it goes. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Fri, Apr 10, 2009 at 11:46 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Fri, Apr 10, 2009 at 11:14 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 8 Apr 2009 12:29:50 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: ok. looking here the problme is.. you have a schedule.. that has none of the following: a knowledge of how long tasks will take people available to do the tasks time guaranteed from all the people this schedule doesn't account for any of that. the result will be a date rolls around with none of the stuff done for it. i propose something MUCH simpler. if the aim is stability in stages maybe simply call freeze dates. you have until 30th april to finish your current work, if it's underway. anything not done by then must be disabled/removed/unpatched. work can happen as long as it is compile-time enabled or runtime enabled and has no effect unless enabled. then within a few days of that date tarballs are produced with incremented release numbers. how about that? :) well, maybe i'm too bad at explaining stuff, but my suggestion was exactly that. I don't want to block developers, that's why it is a weekend. But it would be good to ask developers to help test and fix bugs whenever possible. And I tried to put dates that would not bring problems with GSoC since most developers are also mentors or students, and also because it's good to know beforehand when it will happen. I already have my schedule in Google Calendar, I plan to mail the list on Monday with a warning about freeze on Thursday, then one on Thursday and then another on Sunday. Let's see how it goes. AH! And to prove my point and also the packager's point: quaker is trying to update the packages and Vincent just committed a massive change of ecore_*_free() to ecore_*_del(), almost at the same time. Changes like this are very likely to bring problems with missing renames here and there, problems with linkage and so on, so let's try to avoid doing them on the week we'll try to freeze. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Fri, 10 Apr 2009 11:46:08 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Fri, Apr 10, 2009 at 11:14 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 8 Apr 2009 12:29:50 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: ok. looking here the problme is.. you have a schedule.. that has none of the following: a knowledge of how long tasks will take people available to do the tasks time guaranteed from all the people this schedule doesn't account for any of that. the result will be a date rolls around with none of the stuff done for it. i propose something MUCH simpler. if the aim is stability in stages maybe simply call freeze dates. you have until 30th april to finish your current work, if it's underway. anything not done by then must be disabled/removed/unpatched. work can happen as long as it is compile-time enabled or runtime enabled and has no effect unless enabled. then within a few days of that date tarballs are produced with incremented release numbers. how about that? :) well, maybe i'm too bad at explaining stuff, but my suggestion was exactly that. I don't want to block developers, that's why it is a well.. you did have a detailed release schedule on the wiki even a e17 alpha - everything done date :) weekend. But it would be good to ask developers to help test and fix bugs whenever possible. And I tried to put dates that would not bring problems with GSoC since most developers are also mentors or students, and also because it's good to know beforehand when it will happen. sure. I already have my schedule in Google Calendar, I plan to mail the list on Monday with a warning about freeze on Thursday, then one on Thursday and then another on Sunday. Let's see how it goes. i would suggest much longer timeframes myself eg april 30 then 1 weeks to verify everyrthing is stable and fix last minute things, april 7 - snap (announce a known svnrev that is with this snap - make dist the tarballs and upload). then next one may 30... and so on. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Fri, Apr 10, 2009 at 11:13 PM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 10 Apr 2009 11:46:08 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Fri, Apr 10, 2009 at 11:14 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 8 Apr 2009 12:29:50 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: ok. looking here the problme is.. you have a schedule.. that has none of the following: a knowledge of how long tasks will take people available to do the tasks time guaranteed from all the people this schedule doesn't account for any of that. the result will be a date rolls around with none of the stuff done for it. i propose something MUCH simpler. if the aim is stability in stages maybe simply call freeze dates. you have until 30th april to finish your current work, if it's underway. anything not done by then must be disabled/removed/unpatched. work can happen as long as it is compile-time enabled or runtime enabled and has no effect unless enabled. then within a few days of that date tarballs are produced with incremented release numbers. how about that? :) well, maybe i'm too bad at explaining stuff, but my suggestion was exactly that. I don't want to block developers, that's why it is a well.. you did have a detailed release schedule on the wiki even a e17 alpha - everything done date :) well, people asking for it! they even complained i make it so far away ;-) weekend. But it would be good to ask developers to help test and fix bugs whenever possible. And I tried to put dates that would not bring problems with GSoC since most developers are also mentors or students, and also because it's good to know beforehand when it will happen. sure. I already have my schedule in Google Calendar, I plan to mail the list on Monday with a warning about freeze on Thursday, then one on Thursday and then another on Sunday. Let's see how it goes. i would suggest much longer timeframes myself eg april 30 then 1 weeks to verify everyrthing is stable and fix last minute things, april 7 - snap (announce a known svnrev that is with this snap - make dist the tarballs and upload). then next one may 30... and so on. well, I did it small to try to not impact people (mostly you) so much, if you think it will not, then fine just change the schedule. The bad thing is that I need to go through my calendar and reschedule all the events :-P -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
I just wanted to understand a pair of things... 1) is this something official or just your idea Gustavo? (I love the idea, I'd prefer it to be official of course) 2) will we set up a repo? An official repo to compile everything periodically? This question I'm asking is because for OpenGEU we have a repository, quaker manages it, and he periodically compiles E17. Thanks for your answers, bye, Luca D.M. 2009/4/9 Toma tomha...@gmail.com 2009/4/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Wed, Apr 8, 2009 at 6:58 PM, Toma tomha...@gmail.com wrote: 2009/4/8 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, As you might know we have to do the following list in order to release: http://trac.enlightenment.org/e/wiki/Release But until then we'll have a long time and it's bad to not have intermediate releases to help users try enlightenment and its libraries. So talking to lots of packagers and distros we know they want to include our code, but they need us to have something good enough to be packaged, so they will not be caught into eina-transition breakage or so. So we talked a bit at IRC and I wrote the following schedule that we'll try to accomplish: http://trac.enlightenment.org/e/wiki/ReleaseSchedule Im not entirely sure that the 3 day package-test-package idea is good. Might just be creating more work for whoever packages it and some confusion for end users. well, packagers can live with it, just make a script and schedule a cron tab. as for users, end users can test on the second release, maybe we just drop the announcement of the first and add it to a -testing directory. But we need to test the packages and not from SVN as we usually do, so we can spot missing libs, symbols, etc. Sure. Well we'll just shift the announcement to the 2nd package release. *thumbs up* -Toma -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
I may be off-topic, but to manage these automatic builds, Gustavo suggested a script+crontab. Maybe we could also take advantage of a better solution that does the stuff for us and give back statistics. One of these tools is called buildbot (http://buildbot.net/trac) and it seems to do a good work. Can the devs have a look at it and see whether it would be worth using it ? As a user, I would be glad to consult a report page about all the nightly builds. This helps avoiding regression as well IMO. thanks for the effort Gustavo ! regards, Lionel On Thu, Apr 9, 2009 at 8:34 AM, Luca De Marini luca.darkmas...@gmail.com wrote: I just wanted to understand a pair of things... 1) is this something official or just your idea Gustavo? (I love the idea, I'd prefer it to be official of course) 2) will we set up a repo? An official repo to compile everything periodically? This question I'm asking is because for OpenGEU we have a repository, quaker manages it, and he periodically compiles E17. Thanks for your answers, bye, Luca D.M. 2009/4/9 Toma tomha...@gmail.com 2009/4/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Wed, Apr 8, 2009 at 6:58 PM, Toma tomha...@gmail.com wrote: 2009/4/8 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, As you might know we have to do the following list in order to release: http://trac.enlightenment.org/e/wiki/Release But until then we'll have a long time and it's bad to not have intermediate releases to help users try enlightenment and its libraries. So talking to lots of packagers and distros we know they want to include our code, but they need us to have something good enough to be packaged, so they will not be caught into eina-transition breakage or so. So we talked a bit at IRC and I wrote the following schedule that we'll try to accomplish: http://trac.enlightenment.org/e/wiki/ReleaseSchedule Im not entirely sure that the 3 day package-test-package idea is good. Might just be creating more work for whoever packages it and some confusion for end users. well, packagers can live with it, just make a script and schedule a cron tab. as for users, end users can test on the second release, maybe we just drop the announcement of the first and add it to a -testing directory. But we need to test the packages and not from SVN as we usually do, so we can spot missing libs, symbols, etc. Sure. Well we'll just shift the announcement to the 2nd package release. *thumbs up* -Toma -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Thu, Apr 9, 2009 at 3:34 AM, Luca De Marini luca.darkmas...@gmail.com wrote: I just wanted to understand a pair of things... 1) is this something official or just your idea Gustavo? (I love the idea, I'd prefer it to be official of course) well, it's as official as we want it to be, but it was originally my idea. Nobody seems to disagree so far, in this case we can make it official. 2) will we set up a repo? An official repo to compile everything periodically? that's up to you. I'm a developer, as raster and others. We don't want to waste our few hacking hours to do packages, its way too bureaucratic to my taste. We just want you packagers to have a consistent global state to use. But I'd like to see you all agree and avoid thousands of half working repositories all around, just in launchpad.net we have 2 e17 packaging teams, none is complete or updated. So you all agree and if you need space at enlightenment.org, please ask here so those that care about infrastructure can set up things. This question I'm asking is because for OpenGEU we have a repository, quaker manages it, and he periodically compiles E17. yes, I'm talking a lot with quaker, Lutin and other interested peers over the past days. I'm trying to have everyone to understand these things. For example, if you want to have ecomorph, just handle e17 as a virtual package, have 2 implementations that conflicts/replaces each other, e17-pristine and e17-ecomorph, then you should just have modules that can be used by both to depend on the virtual and that's fine, do not need to create a whole new repository just to have ecomorph. and please, let's try to get these things upstream into debian, ubuntu and others. At least the base libraries and e17 itself. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
2009/4/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Thu, Apr 9, 2009 at 3:34 AM, Luca De Marini luca.darkmas...@gmail.com wrote: I just wanted to understand a pair of things... 1) is this something official or just your idea Gustavo? (I love the idea, I'd prefer it to be official of course) well, it's as official as we want it to be, but it was originally my idea. Nobody seems to disagree so far, in this case we can make it official. Good, I think if it gets official is really better. 2) will we set up a repo? An official repo to compile everything periodically? that's up to you. I'm a developer, as raster and others. We don't want to waste our few hacking hours to do packages, its way too bureaucratic to my taste. We just want you packagers to have a consistent global state to use. But I'd like to see you all agree and avoid thousands of half working repositories all around, just in launchpad.net we have 2 e17 packaging teams, none is complete or updated. So you all agree and if you need space at enlightenment.org, please ask here so those that care about infrastructure can set up things. As for OpenGEU we have a space at Linuxfreedom for the repos. Quaker uses those repos and builds debs of E17 periodically already as I sais, we will keep using them if you are not going to create another adress. My suggestion is we can use our repos to upload these packages :) Just talk with quaker about it, he's the repos boss! This question I'm asking is because for OpenGEU we have a repository, quaker manages it, and he periodically compiles E17. yes, I'm talking a lot with quaker, Lutin and other interested peers over the past days. I'm trying to have everyone to understand these things. For example, if you want to have ecomorph, just handle e17 as a virtual package, have 2 implementations that conflicts/replaces each other, e17-pristine and e17-ecomorph, then you should just have modules that can be used by both to depend on the virtual and that's fine, do not need to create a whole new repository just to have ecomorph. Yes he told me, we will do it for sure. and please, let's try to get these things upstream into debian, ubuntu and others. At least the base libraries and e17 itself. Of course. We will be in upstream, I'm sure of it, when we'll be stable. For Ubuntu at least. I don't know debian policies but Ubuntu won't host officially our E17 packages unless they are stable. So, whenever libraries will become stable, we'll be able to ask Ubuntu to host them in their officla repos and time by time, the entire E will hopefully be in Ubuntu :) Don't worry, we'll strictly collaborate, if you wish, to transform this into reality. Greetings, Luca D.M. -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Thu, Apr 9, 2009 at 2:29 PM, Luca De Marini luca.darkmas...@gmail.com wrote: 2009/4/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi and please, let's try to get these things upstream into debian, ubuntu and others. At least the base libraries and e17 itself. Of course. We will be in upstream, I'm sure of it, when we'll be stable. For Ubuntu at least. I don't know debian policies but Ubuntu won't host officially our E17 packages unless they are stable. So, whenever libraries will become stable, we'll be able to ask Ubuntu to host them in their officla repos and time by time, the entire E will hopefully be in Ubuntu :) Don't worry, we'll strictly collaborate, if you wish, to transform this into reality. often we become unstable, with things like moving ecore/evas to eina data types and major refactors, but other than that it works, maybe better than most software that is labeled as stable. Also, it is not true that everything in Ubuntu/Debian is stable and all, you can see how many packages break now and then, how many request you to export weird -DI_KNOW_THIS_IS_UNSTABLE_API and all. Most people here use e17 daily and it works, is stable. Just need to avoid updating during large changes I said, that's why I want these weekend freezes to help. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
2009/4/8 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, As you might know we have to do the following list in order to release: http://trac.enlightenment.org/e/wiki/Release But until then we'll have a long time and it's bad to not have intermediate releases to help users try enlightenment and its libraries. So talking to lots of packagers and distros we know they want to include our code, but they need us to have something good enough to be packaged, so they will not be caught into eina-transition breakage or so. So we talked a bit at IRC and I wrote the following schedule that we'll try to accomplish: http://trac.enlightenment.org/e/wiki/ReleaseSchedule Im not entirely sure that the 3 day package-test-package idea is good. Might just be creating more work for whoever packages it and some confusion for end users. -Toma -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Apr 8, 2009 at 6:58 PM, Toma tomha...@gmail.com wrote: 2009/4/8 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, As you might know we have to do the following list in order to release: http://trac.enlightenment.org/e/wiki/Release But until then we'll have a long time and it's bad to not have intermediate releases to help users try enlightenment and its libraries. So talking to lots of packagers and distros we know they want to include our code, but they need us to have something good enough to be packaged, so they will not be caught into eina-transition breakage or so. So we talked a bit at IRC and I wrote the following schedule that we'll try to accomplish: http://trac.enlightenment.org/e/wiki/ReleaseSchedule Im not entirely sure that the 3 day package-test-package idea is good. Might just be creating more work for whoever packages it and some confusion for end users. well, packagers can live with it, just make a script and schedule a cron tab. as for users, end users can test on the second release, maybe we just drop the announcement of the first and add it to a -testing directory. But we need to test the packages and not from SVN as we usually do, so we can spot missing libs, symbols, etc. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
2009/4/9 Gustavo Sverzut Barbieri barbi...@profusion.mobi: On Wed, Apr 8, 2009 at 6:58 PM, Toma tomha...@gmail.com wrote: 2009/4/8 Gustavo Sverzut Barbieri barbi...@profusion.mobi: Hello all, As you might know we have to do the following list in order to release: http://trac.enlightenment.org/e/wiki/Release But until then we'll have a long time and it's bad to not have intermediate releases to help users try enlightenment and its libraries. So talking to lots of packagers and distros we know they want to include our code, but they need us to have something good enough to be packaged, so they will not be caught into eina-transition breakage or so. So we talked a bit at IRC and I wrote the following schedule that we'll try to accomplish: http://trac.enlightenment.org/e/wiki/ReleaseSchedule Im not entirely sure that the 3 day package-test-package idea is good. Might just be creating more work for whoever packages it and some confusion for end users. well, packagers can live with it, just make a script and schedule a cron tab. as for users, end users can test on the second release, maybe we just drop the announcement of the first and add it to a -testing directory. But we need to test the packages and not from SVN as we usually do, so we can spot missing libs, symbols, etc. Sure. Well we'll just shift the announcement to the 2nd package release. *thumbs up* -Toma -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). - remove last user of evas_hash and evas_list (they did appear between the start of the move and the actual commit) - remove evas_hash and evas_list from Evas. - remove the last standing ecore_list (some use in e modules and ewl mainly) - move to eina module infrastructure for evas, ecore and e. - move to eina rectangle in evas. - move to eina error for displaying error message. - remove ecore magic and use eina magic. That's a small list, representing a little amount of work. But you can just run grep on the svn and start committing small change as most of this item will not impact external API (So I will not be the only one breaking E svn) As always, have fun ! -- Cedric BAIL -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 2:01 PM, Thomas Gstädtner tho...@gstaedtner.net wrote: On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). - remove last user of evas_hash and evas_list (they did appear between the start of the move and the actual commit) - remove evas_hash and evas_list from Evas. - remove the last standing ecore_list (some use in e modules and ewl mainly) - move to eina module infrastructure for evas, ecore and e. - move to eina rectangle in evas. - move to eina error for displaying error message. - remove ecore magic and use eina magic. Should ecore_list stay in and only the doubly linked lists replaced by eina? If ecore_lists will removed, too, it is not only used in e17, but also by some ecore internals, i.e. ecore_path_group. Already gone :-) -- Cedric BAIL -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. Yes, returning Eina_Iterator would be a better solution in many place in the EFL API. Could be faster and more memory efficient for many case, and it will explicitely say that a the content of a list should not be destroyed/modified by the caller. -- Cedric BAIL -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, Feb 25, 2009 at 1:47 PM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). - remove last user of evas_hash and evas_list (they did appear between the start of the move and the actual commit) - remove evas_hash and evas_list from Evas. - remove the last standing ecore_list (some use in e modules and ewl mainly) - move to eina module infrastructure for evas, ecore and e. - move to eina rectangle in evas. - move to eina error for displaying error message. - remove ecore magic and use eina magic. Should ecore_list stay in and only the doubly linked lists replaced by eina? If ecore_lists will removed, too, it is not only used in e17, but also by some ecore internals, i.e. ecore_path_group. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. Yes, returning Eina_Iterator would be a better solution in many place in the EFL API. Could be faster and more memory efficient for many case, and it will explicitely say that a the content of a list should not be destroyed/modified by the caller. beware of being too gung-ho. some of htese (like evas_render_method_list()) are called so rarely you likely just make the api harder to use for no real gain. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Thu, Feb 26, 2009 at 12:22 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: On Wed, 25 Feb 2009 14:41:41 +0100 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 25, 2009 at 2:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Feb 25, 2009 at 9:47 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Feb 24, 2009 at 10:33 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jan 28, 2009 at 9:04 PM, Toma tomha...@gmail.com wrote: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) So time has come and we're working on that release list. In the last days I've being working on some show stopper stuff like file management and I plan to get ride of most items by March. Did the same on the eina front :) Some items in the list are very demanding, like finish converting ecore data types to eina, but Cedric has some pending patches in queue. If people can help with these easy items, then we can work on more complex stuff and get E17 released soon, making everybody happy, with ready to use packages in most distros :-) All my pending patch are now in. It should not introduce any regression. Now e_dbus, efreet and ecore should only return Eina_List. Still on the TODO, but this could be done one after another with very small commit : - remove ecore_dlist (replace by eina_list) - remove Ecore_List2 (could be replaced by eina_inlist) - review every little loop in the code around list and check, if it would not be better to use EINA_LIST_FREE or EINA_LIST_FOREACH (at the same time, look if we can avoid useless strdup). ... I'd say we should inspect places where lists and specially list *copies* are returned and use eina_iterator or eina_accessor instead. In many places we dup the list (1 walk), then use it (+1 walk), then free it (+1 walk), so 3 walk for a simple task. If we used the iterator stuff we could alloc a small amount of memory and do the same thing, just more clean, safer and faster. Comes to mind evas_render_method_list() and similar. Yes, returning Eina_Iterator would be a better solution in many place in the EFL API. Could be faster and more memory efficient for many case, and it will explicitely say that a the content of a list should not be destroyed/modified by the caller. beware of being too gung-ho. some of htese (like evas_render_method_list()) are called so rarely you likely just make the api harder to use for no real gain. :) not harder, easier! Just get used to iterators and accessors, you'll love them. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
So todays the day to finish all features. I know its a pain in the ass, but would it feasible to start suggesting an ultra-hazy alpha release date? My crystal ball is suggesting August-September. This may motivate people to actually work on these bugs if we have a set date to TRY to get these things done. Additionally, considering GSoC is fast approaching, so we might be able to get some more developers on board if we get accepted again. Might be a good idea to get a wiki together on how to get involved in E bug squishing so we can link to it for any prospective developers? Toma. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
There was a systray mention on there a while ago... maybe it was a different TODO list. Added in modules-extra for now. ok. thx. 3) annoying question related to the color and font config modules. as it was mentioned by Raster: thats what i meant - just wouldn't compile the color and font config modules. they they wont appear anywhere. code will be there - just not being compiled or used until its fixed. ok. but does it mean that all themes/(.edj files) which use custom fonts and/or color_class:-es will require maintenance? if Yes!, then suppose that the info should be spread all over the community or only new default theme will remain usable (it's a nice option, but some may prefer other variants). I think scraping the modules to config it would be good, but leave the support for it via enlightenment_remote would be good as well. If anyone was keen, they could revamp it and reintroduce into a major release eg, E17.1. That way, we dont need to alter themes, and if you really want, just include a brief howto in the theme about. Kind of like what i did with Cerium. please read this thread: http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg20486.html and your response unfortunately doesn't answer the question: does it mean that all themes/(.edj files) which use custom fonts and/or color_class:-es will require maintenance? the milestone left this point as pending (optional). just suppose that clarification is needed. 6) as i mentioned in trac ticket #201 the gap exist in a window management between E16/eesh and E17/enlightenment_remote. it could be nice to eliminate this mismatch especially for the experienced Users of E16. Like buying a new TV, you need to learn the new remote. :) the question is not in learning a new remote unfortunately. it's more related to the should we buy this new TV or let's look at another one? just for fun you can read trac ticket #201 and try to make the same trick with E17. should i prepare the draft of a Comparison Table and outline the mismatches in general? just assumed that we're all here know a bit about the roots and no such things are needed. frankly speaking it doesn't matter will the same functions (like eesh has) work with enlightenment_remote or via qdbus (we're usind dbus now, right?). but i guess that a simple questions like How many windows/apps are running under E? should have an answer readable in your terminal app. eesh has a clear answer: eesh window_list. that's it. What we SHOULD worry about, is the cross themeing of E with EWL and ETK. It is all very possible, but as a themer yourself, its quite tedious to add the other parts and duplicate and so on. We could of course, investigate making the toolkits (Or toolkit) work with edje parts from an E theme. nice point. agree with you. but... let's say that IMHO - ETK has a stable API and a bunch of a software which work for my Linux and OpenBSD. EWL is constantly evolving and assume that the Ephoto app is the only one in a pure EWL basket (plus Elitaire?). also elementary is coming, right? that's why all my modest .edj files contain E17 + ETK only. and the final question is: - several unified themes exist (yep, i created the first one... my fault). can we expect a unified switcher to control the look of E17, ETK and EWL from a single location/app? regards, sda -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On 09:04 Thu 29 Jan , Toma wrote:
As the top of the page says, we need to finalize the list of things
TODO.
hi guys,
i'm not the dev so beg your pardon if things below are out of scope.
1) after the review of a mentioned page
(http://trac.enlightenment.org/e/wiki/Release)
i decide to fill 'trac' with some more 'tickets'/(requests) instead of
the page modification. assume that it's your (and not mine) decision to
set a milestone to the Release.
2) there're no 'magic' word we're all aware about (no doubt that it ...
you know...). here it is (in capital letters):
== SYSTRAY ==
suppose that clear definition of our POV to this case is required. it's
o'k not to make one and explain why. but Release of a Desktop Shell
without a tray will attract less Users i guess. yes, Wiki FAQ advise to
use 'trayer', 'stalonetray', etc., but references to the various
discussions are unable to state the case clear.
3) annoying question related to the color and font config modules. as
it was mentioned by Raster:
thats what i meant - just wouldn't compile the color and font config modules.
they they wont appear anywhere. code will be there - just not being compiled or
used until its fixed.
ok. but does it mean that all themes/(.edj files) which use custom fonts
and/or color_class:-es will require maintenance? if Yes!, then
suppose that the info should be spread all over the community or only new
default theme will remain usable (it's a nice option, but some may
prefer other variants).
4) another chewing gum - Should add lua support? (optional) Just
make a decision and say it. No/Yes - doesn't matter much (though the
amount of maintenance if Yes will be sufficient). it's a pity that
both VM's ('embryo' and 'lua') can't exist together.
5) last couple of days i'm using 'Ecomorph' and it's much more stable
then bling module. suppose that bling should be improved (in terms
of stability) or explicitly marked as 'unstable'. yes, FAQ tells that
E17 doesn't work with composite, but it's an easy task for bling now
to create a nice segfault of E17 :).
offtop http://en.opensuse.org/Ecomorph
6) as i mentioned in trac ticket #201 the gap exist in a window
management between E16/eesh and E17/enlightenment_remote. it could be
nice to eliminate this mismatch especially for the experienced Users
of E16.
7) the bridge between qt - edje gtk - edje still under
heavy discussion suggest to create a couple of themes like existing
Clearlooks (it's really nice) to match the major ones used by others.
dunno about qt (don't use it here) but it's an easy task to copy a
couple of most popular gtk+ ones.
thanks for your kind attention.
regards,
sda
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Thu, 29 Jan 2009 16:29:12 +0300 sda dmitry.serpok...@gmail.com said:
On 09:04 Thu 29 Jan , Toma wrote:
As the top of the page says, we need to finalize the list of things
TODO.
hi guys,
i'm not the dev so beg your pardon if things below are out of scope.
1) after the review of a mentioned page
(http://trac.enlightenment.org/e/wiki/Release)
i decide to fill 'trac' with some more 'tickets'/(requests) instead of
the page modification. assume that it's your (and not mine) decision to
set a milestone to the Release.
ugh. now i need to find all the tickets spread around with bugs and feature
requests too... much harder that just reading the page and knocking off line
items and deleting them.
2) there're no 'magic' word we're all aware about (no doubt that it ...
you know...). here it is (in capital letters):
== SYSTRAY ==
suppose that clear definition of our POV to this case is required. it's
o'k not to make one and explain why. but Release of a Desktop Shell
without a tray will attract less Users i guess. yes, Wiki FAQ advise to
use 'trayer', 'stalonetray', etc., but references to the various
discussions are unable to state the case clear.
not happening. tray protocol/mechanism is broken as fare as e is concerned.
3) annoying question related to the color and font config modules. as
it was mentioned by Raster:
thats what i meant - just wouldn't compile the color and font config modules.
they they wont appear anywhere. code will be there - just not being compiled
or used until its fixed.
ok. but does it mean that all themes/(.edj files) which use custom fonts
and/or color_class:-es will require maintenance? if Yes!, then
suppose that the info should be spread all over the community or only new
default theme will remain usable (it's a nice option, but some may
prefer other variants).
nothing is needed from themes - nada. simply users will not be able to
fine-tune config for private DIFFERENT fonts and colors. they get what the
theme gives them.
4) another chewing gum - Should add lua support? (optional) Just
make a decision and say it. No/Yes - doesn't matter much (though the
amount of maintenance if Yes will be sufficient). it's a pity that
both VM's ('embryo' and 'lua') can't exist together.
they can. the question is - do we want to ship with a vm/scripting engine we
WILL drop in the future thus having a pain for people post-release of having to
adapt stuff they built on 1.0 releases.
5) last couple of days i'm using 'Ecomorph' and it's much more stable
then bling module. suppose that bling should be improved (in terms
of stability) or explicitly marked as 'unstable'. yes, FAQ tells that
E17 doesn't work with composite, but it's an easy task for bling now
to create a nice segfault of E17 :).
not touching bling. compositing is scheduled for e18 - for e17 it's a someone
elses problem. you chose to use bling - you should take it up with bling's
author/maintainer. :) e is not doing compositing itself until e18.
offtop http://en.opensuse.org/Ecomorph
6) as i mentioned in trac ticket #201 the gap exist in a window
management between E16/eesh and E17/enlightenment_remote. it could be
nice to eliminate this mismatch especially for the experienced Users
of E16.
removing almost all of e_remote. the window management features of eesh are of
niche use and can be done by simply x tools without the wm. feel free to write
these tools. :) no need to go add work for e17 release for something that has
no need to be in e.
7) the bridge between qt - edje gtk - edje still under
heavy discussion suggest to create a couple of themes like existing
Clearlooks (it's really nice) to match the major ones used by others.
dunno about qt (don't use it here) but it's an easy task to copy a
couple of most popular gtk+ ones.
to be honest - gtk and qt are out of scope for e17 release when it comes to
edje or evas.
thanks for your kind attention.
regards,
sda
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
On Thu, Jan 29, 2009 at 2:04 AM, Toma tomha...@gmail.com wrote: I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) -Toma. Ahaha, indeed. -- Veli Sungutay http://www.lyciasoft.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
2009/1/29 sda dmitry.serpok...@gmail.com:
On 09:04 Thu 29 Jan , Toma wrote:
As the top of the page says, we need to finalize the list of things
TODO.
hi guys,
i'm not the dev so beg your pardon if things below are out of scope.
1) after the review of a mentioned page
(http://trac.enlightenment.org/e/wiki/Release)
i decide to fill 'trac' with some more 'tickets'/(requests) instead of
the page modification. assume that it's your (and not mine) decision to
set a milestone to the Release.
2) there're no 'magic' word we're all aware about (no doubt that it ...
you know...). here it is (in capital letters):
== SYSTRAY ==
suppose that clear definition of our POV to this case is required. it's
o'k not to make one and explain why. but Release of a Desktop Shell
without a tray will attract less Users i guess. yes, Wiki FAQ advise to
use 'trayer', 'stalonetray', etc., but references to the various
discussions are unable to state the case clear.
There was a systray mention on there a while ago... maybe it was a
different TODO list. Added in modules-extra for now.
3) annoying question related to the color and font config modules. as
it was mentioned by Raster:
thats what i meant - just wouldn't compile the color and font config modules.
they they wont appear anywhere. code will be there - just not being compiled
or
used until its fixed.
ok. but does it mean that all themes/(.edj files) which use custom fonts
and/or color_class:-es will require maintenance? if Yes!, then
suppose that the info should be spread all over the community or only new
default theme will remain usable (it's a nice option, but some may
prefer other variants).
I think scraping the modules to config it would be good, but leave the
support for it via enlightenment_remote would be good as well. If
anyone was keen, they could revamp it and reintroduce into a major
release eg, E17.1. That way, we dont need to alter themes, and if you
really want, just include a brief howto in the theme about. Kind of
like what i did with Cerium.
4) another chewing gum - Should add lua support? (optional) Just
make a decision and say it. No/Yes - doesn't matter much (though the
amount of maintenance if Yes will be sufficient). it's a pity that
both VM's ('embryo' and 'lua') can't exist together.
More of a pending decision. Someone was working on an alternate
environment with LUA working. Results of that work are yet to be
debated and trialed I guess? My personal
5) last couple of days i'm using 'Ecomorph' and it's much more stable
then bling module. suppose that bling should be improved (in terms
of stability) or explicitly marked as 'unstable'. yes, FAQ tells that
E17 doesn't work with composite, but it's an easy task for bling now
to create a nice segfault of E17 :).
offtop http://en.opensuse.org/Ecomorph
Only thing stopping ecomorph from being an official module is that it
needs drastic changes to the main tree, IIRC. Someone feel free to
correct me on that as I havent looked into it.
6) as i mentioned in trac ticket #201 the gap exist in a window
management between E16/eesh and E17/enlightenment_remote. it could be
nice to eliminate this mismatch especially for the experienced Users
of E16.
Like buying a new TV, you need to learn the new remote. :)
7) the bridge between qt - edje gtk - edje still under
heavy discussion suggest to create a couple of themes like existing
Clearlooks (it's really nice) to match the major ones used by others.
dunno about qt (don't use it here) but it's an easy task to copy a
couple of most popular gtk+ ones.
With the development of QEdje, a cross to QT/KDE with an E theme might
be possible with a bit more persistence. But again, I havent even
looked at QEdje and friends since they were released a while back. But
in all honesty, we shouldnt worry too much about that. What we SHOULD
worry about, is the cross themeing of E with EWL and ETK. It is all
very possible, but as a themer yourself, its quite tedious to add the
other parts and duplicate and so on. We could of course, investigate
making the toolkits (Or toolkit) work with edje parts from an E theme.
thanks for your kind attention.
regards,
sda
NP.
Toma-
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Release schedule
Furthermore, I just added a note to the wiki page to add your name/nick (and if you want, email) to whatever item or items you might be working on so others can start crossing off some of the items. So if you are interested in claiming one of the TODOs, now would be a good time. -Toma 2009/1/29 Toma tomha...@gmail.com: Thought Id ping the mailing list about this: http://trac.enlightenment.org/e/wiki/Release As the top of the page says, we need to finalize the list of things TODO. Mekius mentioned removing a couple of the EFM todos and Id welcome that. Im in the process of finishing off the icons, but think some of the dialogs could either get the chop, or get renamed. One of these is 'Interactions', as it has a pile of thumbscroll options. Shall we set a date for closing off the TODO feature list? Any additions after that date will be bugs related to the features. I propose February 14th. Its close, realistic, and might dull the loneliness of Valentines Day. :) -Toma. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
