Re: [E-devel] Eina
Before this turns completely into another license flame-war. Let's step back and look at this from a more practical standpoint. I'm going to list the set of arguments mentioned as to why we need LGPL, since that is the point being argued, along with questions that would need to be answered for this change to make sense. Argument 1. Our community has failed to grow because of our choice of license. Question 1. What proof exists that choice of license has repelled more people than it has attracted? Counter 1. Most users don't weigh choice of license into their decision to use a product. Even among open source users they are happy if the software uses an OSI approved license. It's very common that users don't even realize E is BSD. Counter 2. E has attracted a large number of users over the years and many of them have moved on to other things. Of the users that have left the project, the choice of license is never brought up as the reason. It is almost always around the lack of progress, the need for better integration with their applications, or finding another environment they prefer over E. Among our developers it's usually because other obligations require too much time to contribute to the project any longer, or simply a change in priorities in their lives. Argument 2. Attracting more companies will grow our community. Question 1. Is expanded business use the best way to grow our community? Counter 1. In most successful open source projects the support from the business community comes after the user base has reached a self-sustaining level with a reasonable growth rate. While E has maintained a self-sustaining level over the years, we have a stagnant growth rate. For the last few years we have a pretty consistent incoming developer base of approximately the same size as the developers that are leaving the project or cutting back their time spent on it. Counter 2. While businesses make valuable contributions to help polish projects and develop key features, they are not usually the driving force behind successful projects. In most cases, the projects that have become too corporate have seen declining community contributions. The extreme case of this is code which was started by a company and that company has basically been doing all development, just in the open. This can lead to projects that are too easily swayed by corporate considerations or changes in strategy. MySQL is a good example of this scenario. Argument 3. Companies can legally use and change our code without giving back. Question 1. How does LGPL prevent this from happening? Counter 1. The LGPL prevents this only if they make changes directly within the code and distribute the end product. Since linking is specifically allowed, a company can write a thin wrapper which extends the lib with the functionality they want and just link in the existing code. Counter 2. There is also the possibility of going the other direction, as they could export the functionality that they want as a lib and re-distribute the small changes within our code that access their lib. Counter 3. The binary from the modified code is not directly distributed to end users. For instance with a web service or other client-server model, there is no requirement in most OSI approved license that these modifications be distributed. Question 2. How valuable are the companies changes to the community? Counter 1. Most of our code is commodity software, especially the lower level libs. The advantage we bring is providing an entire stack of software for development, which is flexible enough to use only certain components when appropriate. There are many alternative implementations of what we're providing, and the area we differentiate currently is the uniformity of API's and the presence of Edje. Most companies already have some equivalent of the functionality either through standard libs in their language, internal or proprietary implementations, or other open source options. Counter 2. If the modifications are very specific to the companies development environment, then there is little value added to the community if they are given back. For instance, if they have custom build environments, the modifications to work in that environment don't benefit the community and pollute our code with dependencies useful to a very specific use case. Sharing these modifications also exposes proprietary information about the companies environment which it may not want to share. Counter 3. Historically, companies have found it more valuable to share code back with the community rather than to maintain separate forks with their custom modifications. There are plenty of examples of this throughout the history of the BSD systems, but two that are commonly cited are the NFS filesystem from Sun, and Darwin from Apple. Argument 4. Companies won't use our code because it's BSD licensed. Question 1. How are these companies coming to this decision? Counter 1. If a company is not
Re: [E-devel] Eina ideas and requests
On Sat, Aug 2, 2008 at 9:49 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: I don't want everyone to always use it, it can be kept as a helper and people who wish to have an abstract data model (usually void *) and access it as a list can provide the iterator. I use it in my mvc lists, something like: model_set(void *model, eina_iterator_t *(*accessor_constructor)(void *model)) and whenever I want to iterate the whole list, I delete the old, create a new and start the loop. I think the iterator should be absolutely required to access the list contents. There have been many bugs in code that uses evas_lists simply because the API is designed to maintain references into internal structures (the list nodes). The mempool makes this even more difficult to debug since the nodes are not freed, and are often re-used as other list nodes. Even if they are not re-used, they can contain pointers within the remnants of the list and so appears valid. It's a bit different as it's an external structure, you can create as much iterators or accessors as you want and use them in different ways. What you CAN'T is modify the iterated/accessed object while it's in use. This is basically what we've been proposing for ecore_lists except for the non-modify requirement. What reason do you have for not allowing any modifications through the iterators? Nathan - 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] [e-users] [website] What would you like to see on the new site?
On 04/08/2008, Ian Caldwell [EMAIL PROTECTED] wrote: absolutely and I believe in redoing the navigation would involve redoing the site. If anyone would like to share any other mock ups other than mekius go ahead. I personally like simple site designs like this: http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png(flame me if you want) minus the fact that I think the inkscape in brief section should be just a wider news section and take the little news box off the side. but I like designs like that because they list all the links to the different web software. Songbird does this on their site too but their site is a little too busy http://getsongbird.com/ just my thoughts I like the Inkscape mockup. Looks professional and has all the content at a place thats very easy to see. The icons help too for those that dont know english and cant be bothered switching to their language translation. Songbird one give me the idea of using some cool ajax for the icons. Since EFL and all can do cool animations, maybe something neat like that could make its way into the website? Toma On Sun, Aug 3, 2008 at 9:06 PM, dan sinclair [EMAIL PROTECTED] wrote: On 3-Aug-08, at 10:07 PM, Nick Hughart wrote: Carsten Haitzler (The Rasterman) wrote: On Fri, 01 Aug 2008 13:33:34 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Ian Caldwell wrote: Yup, I'd like to eliminate submenus completely One navigation on all pages that has links to pretty much everything. The goal of the new site is make it a lot more usable. With regularly updated news, and a lot of static content around it. This is bad design imo, it leads to overload. Having to dig through a ton of links to find the one you want is crazy, it's best to be able to filter towards your goal IMO. Much easier to filter then to try and find a link among many that sounds like what you want. This is how my brain works anyway. we don't need some new navigation system... we need to simplify content, only put up what we absolutely need on the e.org brochure site (it's meant to be a simple couple of pages brochure/flier like set of pages with just the minimum needed to find out what e is, who is involved, how/where to get it). the other bits (trac/bugzilla, wiki, docs etc. etc.) are what is intended for large-scale documentation and info - and those (the wiki especially) is READILY accessible to people to edit. Yes, I realize this, most of the links in the submenus will just point to the wiki/tracker/etc. But people found it hard to even find these things on the current site. So it would be nice to point them to where they need to look instead of them having to decode links that don't necessarily match anything they are looking for. So the changes to navigation are nothing stellar, just reorganizing the menu and making the submenu a little more visible so people immediately see things to click on. At least this is what I did with my mockup, haven't seen anyone else come forward with anything yet. I'm with Mekius. The number one complaint that I get about the website is that the navigation sucks. If we can do something to make it easier for people to find stuff then it's a win. 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 - 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 - 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
Re: [E-devel] RFC: embryo release in 2 weeks
On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. :( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. -- Cedric BAIL - 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] Eina ideas and requests
On Sat, Aug 2, 2008 at 4:49 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
great!
Making eina thread safe is one of the goal. As I care about
performance, I just don't know how, but definitively on the road map.
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
I don't want everyone to always use it, it can be kept as a helper and
people who wish to have an abstract data model (usually void *) and
access it as a list can provide the iterator. I use it in my mvc
lists, something like: model_set(void *model, eina_iterator_t
*(*accessor_constructor)(void *model)) and whenever I want to iterate
the whole list, I delete the old, create a new and start the loop.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
It's a bit different as it's an external structure, you can create as
much iterators or accessors as you want and use them in different
ways. What you CAN'T is modify the iterated/accessed object while it's
in use.
Similar to eina_iterator:
typedef struct eina_accessor {
int (*get)(eina_acessor_t *accessor, int index, void **data);
void (*free)(eina_accessor_t *accessor);
} eina_acessor_t;
When you want to create an accessor for Evas_List, you extend this
with some members:
struct eina_accessor_evas_list {
eina_accessor_t base;
const Evas_List *head;
struct {
const Evas_List *node;
int index;
} last_used;
}
when you access some index you calculate: am I near to 'index' going
from head (0), tail (evas_list_count()) or last_used index? Than you
calculate the direction and how many items you have to go.
This accessor and iterator stuff sounds interresting feature to me
too. I am going to add them to eina during the week. Do people want
this also for inlist too ?
--
Cedric BAIL
-
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] RFC: embryo release in 2 weeks
On Mon, 4 Aug 2008 11:17:30 +0200 (CEST) Dave Andreoli [EMAIL PROTECTED] babbled: I think removing embryo now is not a good idea, there are tons of stuff that use embryo (also for just a toggle button). For example half of the projects I have done use embryo (gadman, edje editor, CALCULATOR). IMO is better to leave developers some time to switch to the new engine. I also agree with the use of lua for all the above reason and becouse I liked it in scite scripting. And now that the plan seems real I need to ask the first feature request! Please when you reimplement scripting in edje let the ability to get/modify the source of the various scripts (edje now keep track only of the bytecode code for the scripts). This will solve the biggest issue in edje_editor :) definitely will. the lua code will be in the .edj as source - as lua really likes reading its source and parsing... so u'll have the src there! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] RFC: embryo release in 2 weeks
On Mon, 4 Aug 2008 10:50:10 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. :( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. man.. thank you! a man who has actually played with spidermonkey and js.. and real advice from the trenches! thanks muchly! confirms my thoughts that lua is a much better fit. i was thinking of getting lua in by end of august... i need to play with it first... the question is.. embryo - keep for compatibility (after the lua change) or throw out? i would keep it anyway while adding lua... but then.. remove or not? i am listening to those using embryo right now. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] RFC: embryo release in 2 weeks
- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: On Mon, 4 Aug 2008 10:50:10 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. :( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. man.. thank you! a man who has actually played with spidermonkey and js.. and real advice from the trenches! thanks muchly! confirms my thoughts that lua is a much better fit. i was thinking of getting lua in by end of august... i need to play with it first... the question is.. embryo - keep for compatibility (after the lua change) or throw out? i would keep it anyway while adding lua... but then.. remove or not? i am listening to those using embryo right now. I think removing embryo now is not a good idea, there are tons of stuff that use embryo (also for just a toggle button). For example half of the projects I have done use embryo (gadman, edje editor, CALCULATOR). IMO is better to leave developers some time to switch to the new engine. I also agree with the use of lua for all the above reason and becouse I liked it in scite scripting. And now that the plan seems real I need to ask the first feature request! Please when you reimplement scripting in edje let the ability to get/modify the source of the various scripts (edje now keep track only of the bytecode code for the scripts). This will solve the biggest issue in edje_editor :) Thanks Dave -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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 - 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] RFC: embryo release in 2 weeks
- Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] ha scritto: On Mon, 4 Aug 2008 11:17:30 +0200 (CEST) Dave Andreoli [EMAIL PROTECTED] babbled: I think removing embryo now is not a good idea, there are tons of stuff that use embryo (also for just a toggle button). For example half of the projects I have done use embryo (gadman, edje editor, CALCULATOR). IMO is better to leave developers some time to switch to the new engine. I also agree with the use of lua for all the above reason and becouse I liked it in scite scripting. And now that the plan seems real I need to ask the first feature request! Please when you reimplement scripting in edje let the ability to get/modify the source of the various scripts (edje now keep track only of the bytecode code for the scripts). This will solve the biggest issue in edje_editor :) definitely will. the lua code will be in the .edj as source - as lua really likes reading its source and parsing... so u'll have the src there! :) Great, thanks! Dave -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] RFC: embryo release in 2 weeks
On Mon, Aug 4, 2008 at 10:54 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 4 Aug 2008 10:50:10 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. :( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. man.. thank you! a man who has actually played with spidermonkey and js.. and real advice from the trenches! thanks muchly! confirms my thoughts that lua is a much better fit. i was thinking of getting lua in by end of august... i need to play with it first... the question is.. embryo - keep for compatibility (after the lua change) or throw out? i would keep it anyway while adding lua... but then.. remove or not? i am listening to those using embryo right now. If it was just me I said just drop it. But if we really want to have a smooth path, we can just choose the same path as for eet file format change, drop a warning for a few month, then disable its support by default in configure and later completely remove it. During the time, embryo binding will not receive any more improvement. -- Cedric BAIL - 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] [e-users] [website] cms?
Having it handled by CVS instead of a webgui-CMS doesn't mean to have no CMS at all. There are some CM-systems out there that can create the content out of simple text files with a simple markup language. This would allow to keep the CVS structure and have people to write articles without having to mess around with web developing. There's an even more interesting project, called WCV (web content viewer). It's basically a CMS that creates content out of text files with a basic markup. The cool thing is, that it even uses SVN (or CVS) metadata to track revisions and so on. It supports RSS and some stuff like this, but is still not functional enough to be used directly. Anyway - the concept is interesting and something like this might be a good choice. Here's the link: http://web-content-viewer.org/ On Sat, Aug 2, 2008 at 9:23 PM, dan sinclair [EMAIL PROTECTED] wrote: On 2-Aug-08, at 2:55 PM, Sthithaprajna Garapaty wrote: I'm not saying having a CMS will suddenly bring people to write. That's a separate problem. I think it will not BLOCK people from writing. There's a difference. There are various avenues we can pursue to attract writers. Bounties, request for articles on the front page, etc can easily attract writers. Also, we need to have a strict no drinking and writing policy. Nothing we have now blocks people from writing (and this is coming from the guy that wrote a _lot_ of documentation for Ewl and the EFL). Use your blog. Use the wiki. Everything is available. If people wanted to write they'd be doing it already. If we have to pay them, then I'd say they're just in it for the money. Probably not the type of community we want to foster. 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 - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, 2008-08-04 at 21:19 +1000, Carsten Haitzler wrote: ok. first - i know there will be unhappiness and disagreements. but i've been thinking and it's time to stop the status-quo here. some people will be pissed off, some will just be mildly unhappy, some not care, some be happy and some overjoyed. i ask to leave flamethrowers at the door. since this has been argued back and forth before and everyone has said their piece... it's nothing new. 1. we have had cvs for a long time - something in the region of a decade of using cvs... we already have an svn server - and i' have brought it up to working order: http://svn.enlightenment.org ... it was originally installed as a dependency for trac - and has been lurking, unused. i have added full dev access (there is a devs dir in svn - same devs copied from cvs, with same ssh keys and thus same access as same usernames). all existing devs have access. anonsvn is also working. it also sends mails to [EMAIL PROTECTED] on commits with diffs. https://lists.sourceforge.net/lists/listinfo/enlightenment-svn to subscribe etc. so this is up. it's ready to use - let's use it. using svn instead of cvs is childs play. i won't go into it. why not git? compromise and git is very different. all this needs now is: a. suspend of cvs activity. b. import of existing cvs tree(s) and maybe a re-org in the process, but KEEP HSITORY. i intend to remove the e17 dir and everything inside of it, flatten out to: e17/apps/ - apps/ e17/docs/ - docs/ e17/libs/ - libs/ e17/proto/ - proto/ e17/test/ - test/ we already have: devs/ - devs/ and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules that's an initial import of our existing cvs modules/trees. from there on it's all svn. things can be moved and so on around. (and svn supports rename/mv). c. continue development from there. i hope to get this done in the next few weeks (in august). and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, but start using trac for new feature requests, bug reports etc. i know i intend to anyway. it's just more usable (imho). it's integration with trac's wiki and svn are great. it's overall a good tool. trac is at: http://trac.enlightenment.org/e again. this won't be popular with everyone - but i think it's for the best. we've got too many dangling things to do and things put off - so these are 2 steps of many to get things organised. trac is up and ready now, so simply once svn is moved. start using it. woohoo. finally. it was rather absurd to keep both bugzilla and trac around. - 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] Eina ideas and requests
On Mon, Aug 4, 2008 at 3:16 AM, Nathan Ingersoll [EMAIL PROTECTED] wrote: On Sat, Aug 2, 2008 at 9:49 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: I don't want everyone to always use it, it can be kept as a helper and people who wish to have an abstract data model (usually void *) and access it as a list can provide the iterator. I use it in my mvc lists, something like: model_set(void *model, eina_iterator_t *(*accessor_constructor)(void *model)) and whenever I want to iterate the whole list, I delete the old, create a new and start the loop. I think the iterator should be absolutely required to access the list contents. There have been many bugs in code that uses evas_lists simply because the API is designed to maintain references into internal structures (the list nodes). The mempool makes this even more difficult to debug since the nodes are not freed, and are often re-used as other list nodes. Even if they are not re-used, they can contain pointers within the remnants of the list and so appears valid. my personal experience with such is different. I see more and more people used to manipulate these lists, and if you make it clear you should not modify list while iterating, or you have to take double-care, then errors go to 0. Often I use kernel like macros to do iteration, and they even have macros to deal with lists that can change. I guess the point of direct access is to make it fast, we can make them more safe by using these macros. And the point of iterators is to make various data type access uniform, I can get the iterator for a list, array, chuncked list, hash, ... As for the mempool, AFAIK eina has changeable subsystems, we can do like others and have one subsystem that just malloc/free for ease of debug. It's a bit different as it's an external structure, you can create as much iterators or accessors as you want and use them in different ways. What you CAN'T is modify the iterated/accessed object while it's in use. This is basically what we've been proposing for ecore_lists except for the non-modify requirement. What reason do you have for not allowing any modifications through the iterators? Not a real reason, mostly due simplicity of implementation. If you want to make them modifications-proof, then just keep callbacks between created iterators and when you request some change you walk these and reset their internal pointers. It's a bit more complicated, but safer, yes. When doing such central things I often like to avoid over-engineering the common case, that is walking the objects without modifications, but trying to provide easy ways to do the others so users don't do mistakes. I think that linux kernel (include/linux/list.h) is a good example of that, it's low-overhead, well documented and safe to use. They provide list_for_each() and list_for_each_safe() (and similar) macros. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, Aug 4, 2008 at 1:19 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: ok. first - i know there will be unhappiness and disagreements. but i've been thinking and it's time to stop the status-quo here. some people will be pissed off, some will just be mildly unhappy, some not care, some be happy and some overjoyed. i ask to leave flamethrowers at the door. since this has been argued back and forth before and everyone has said their piece... it's nothing new. 1. we have had cvs for a long time - something in the region of a decade of using cvs... we already have an svn server - and i' have brought it up to working order: http://svn.enlightenment.org ... it was originally installed as a dependency for trac - and has been lurking, unused. i have added full dev access (there is a devs dir in svn - same devs copied from cvs, with same ssh keys and thus same access as same usernames). all existing devs have access. anonsvn is also working. it also sends mails to [EMAIL PROTECTED] on commits with diffs. https://lists.sourceforge.net/lists/listinfo/enlightenment-svn to subscribe etc. so this is up. it's ready to use - let's use it. using svn instead of cvs is childs play. i won't go into it. why not git? compromise and git is very different. all this needs now is: a. suspend of cvs activity. b. import of existing cvs tree(s) and maybe a re-org in the process, but KEEP HSITORY. i intend to remove the e17 dir and everything inside of it, flatten out to: e17/apps/ - apps/ e17/docs/ - docs/ e17/libs/ - libs/ e17/proto/ - proto/ e17/test/ - test/ we already have: devs/ - devs/ and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules that's an initial import of our existing cvs modules/trees. from there on it's all svn. things can be moved and so on around. (and svn supports rename/mv). c. continue development from there. i hope to get this done in the next few weeks (in august). and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, but start using trac for new feature requests, bug reports etc. i know i intend to anyway. it's just more usable (imho). it's integration with trac's wiki and svn are great. it's overall a good tool. trac is at: http://trac.enlightenment.org/e again. this won't be popular with everyone - but i think it's for the best. we've got too many dangling things to do and things put off - so these are 2 steps of many to get things organised. trac is up and ready now, so simply once svn is moved. start using it. Good news, everything on one place. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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 - 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] Eina ideas and requests
On Mon, Aug 4, 2008 at 6:28 AM, Cedric BAIL [EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 4:49 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 11:34 AM, Jorge Luis Zapata Muga
[EMAIL PROTECTED] wrote:
On Sat, Aug 2, 2008 at 9:27 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Hi guys,
I still don't have time to play/help with Eina, but from what I saw so
far, I'd like to propose some ideas and request some features:
- make data types thread safe. I know evas and other libraries are
not thread safe, but not being able to create lists, arrays and hashes
on different threads is too much limited! I'm not talking about append
to the same list from different threads, but creating nodes for
different lists on different threads. Today this will fail because of
mempool and other cache.
I agree with you, making eina thread safe is one of the goals we have.
An making the data types thread safe is a must.
As a side note, there are already comments on such a thing for
eina_error, I'd like to make the error subsystem thread safe, and add
a callback to actually do something when an error wants to be printed
instead of sending the data to stdout, a callback so a an application
might want to write the errors into a file (logging), etc.
great!
Making eina thread safe is one of the goal. As I care about
performance, I just don't know how, but definitively on the road map.
see, I'm talking about mempool here, not really about types being
thread safe. You can do that by either adding locks to current
implementation or choosing another algorithm (?), maybe look at how
others do (glib/gslice, pymalloc, malloc itself).
- provide iterator pattern as a different, complementary system. I'm
using this with Guarana and have iterator for my own list and also
Evas_List. What I have is something as simple as:
eina_iterator_t *eina__iterator_get(_t *object);
int eina_iterator_next(eina_iterator_t *itr, void **data);
void eina_iterator_del(eina_iterator_t *itr);
typedef struct { int (*next)(eina_iterator_t *itr, void
**data); void (*free)(eina_iterator_t *itr) } eina_iterator_t;
users can extend from eina_iterator_t and append required
fields, like current list node. This simplifies iteration and
abstracts if you want to use array, lists and even Python/Perl/JS list
objects.
Yes, this is good too, im not sure if cedric might want it, as he is
some kind of performance addict :) and adding another pointer
reference might slow it down, but i prefer this normalization on the
API, is a trade-off i prefer.
I don't want everyone to always use it, it can be kept as a helper and
people who wish to have an abstract data model (usually void *) and
access it as a list can provide the iterator. I use it in my mvc
lists, something like: model_set(void *model, eina_iterator_t
*(*accessor_constructor)(void *model)) and whenever I want to iterate
the whole list, I delete the old, create a new and start the loop.
- provide accessor (? don't know the real name) pattern, similar to
iterator, this one will access based on index. This one make code
really simple and if you implement it right, for Evas_List you can
have very quick access if you remember last accessed node and search
from head, tail or current position. I also have this code and can
contribute with Evas_List example.
Im not sure if i understood this correctly, but i think what you are
proposing is similar to what Ecore_List do, you keep track of the last
accessed node on one side and the last added/deleted node in the
other, even so IMHO the ecore_list API is not clear enough on what
functions update one or the other, and yes, this is possible, i did an
ecore_list wrapper using evas_list (i gave the reference for it on
another ml thread), and i think is good to have to speed up node
retrieve.
It's a bit different as it's an external structure, you can create as
much iterators or accessors as you want and use them in different
ways. What you CAN'T is modify the iterated/accessed object while it's
in use.
Similar to eina_iterator:
typedef struct eina_accessor {
int (*get)(eina_acessor_t *accessor, int index, void **data);
void (*free)(eina_accessor_t *accessor);
} eina_acessor_t;
When you want to create an accessor for Evas_List, you extend this
with some members:
struct eina_accessor_evas_list {
eina_accessor_t base;
const Evas_List *head;
struct {
const Evas_List *node;
int index;
} last_used;
}
when you access some index you calculate: am I near to 'index' going
from head (0), tail (evas_list_count()) or last_used index? Than you
calculate the direction and how many items you have to go.
This accessor and iterator stuff sounds interresting feature to me
too. I am going to add them to eina during the week. Do people want
this also for inlist too ?
I'd add them
[E-devel] moving things along - cvs - svn and bugs (bugzilla-trac)
ok. first - i know there will be unhappiness and disagreements. but i've been thinking and it's time to stop the status-quo here. some people will be pissed off, some will just be mildly unhappy, some not care, some be happy and some overjoyed. i ask to leave flamethrowers at the door. since this has been argued back and forth before and everyone has said their piece... it's nothing new. 1. we have had cvs for a long time - something in the region of a decade of using cvs... we already have an svn server - and i' have brought it up to working order: http://svn.enlightenment.org ... it was originally installed as a dependency for trac - and has been lurking, unused. i have added full dev access (there is a devs dir in svn - same devs copied from cvs, with same ssh keys and thus same access as same usernames). all existing devs have access. anonsvn is also working. it also sends mails to [EMAIL PROTECTED] on commits with diffs. https://lists.sourceforge.net/lists/listinfo/enlightenment-svn to subscribe etc. so this is up. it's ready to use - let's use it. using svn instead of cvs is childs play. i won't go into it. why not git? compromise and git is very different. all this needs now is: a. suspend of cvs activity. b. import of existing cvs tree(s) and maybe a re-org in the process, but KEEP HSITORY. i intend to remove the e17 dir and everything inside of it, flatten out to: e17/apps/ - apps/ e17/docs/ - docs/ e17/libs/ - libs/ e17/proto/ - proto/ e17/test/ - test/ we already have: devs/ - devs/ and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules that's an initial import of our existing cvs modules/trees. from there on it's all svn. things can be moved and so on around. (and svn supports rename/mv). c. continue development from there. i hope to get this done in the next few weeks (in august). and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, but start using trac for new feature requests, bug reports etc. i know i intend to anyway. it's just more usable (imho). it's integration with trac's wiki and svn are great. it's overall a good tool. trac is at: http://trac.enlightenment.org/e again. this won't be popular with everyone - but i think it's for the best. we've got too many dangling things to do and things put off - so these are 2 steps of many to get things organised. trac is up and ready now, so simply once svn is moved. start using it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] RFC: embryo release in 2 weeks
On Mon, Aug 4, 2008 at 5:50 AM, Cedric BAIL [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. :( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. Excellent to know, so I remove my JS arguments altogether, Lua we go! (but as davemds said later, I'd keep embryo for some time). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, Aug 4, 2008 at 8:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: ok. first - i know there will be unhappiness and disagreements. but i've been thinking and it's time to stop the status-quo here. some people will be pissed off, some will just be mildly unhappy, some not care, some be happy and some overjoyed. i ask to leave flamethrowers at the door. since this has been argued back and forth before and everyone has said their piece... it's nothing new. 1. we have had cvs for a long time - something in the region of a decade of using cvs... we already have an svn server - and i' have brought it up to working order: http://svn.enlightenment.org ... it was originally installed as a dependency for trac - and has been lurking, unused. i have added full dev access (there is a devs dir in svn - same devs copied from cvs, with same ssh keys and thus same access as same usernames). all existing devs have access. anonsvn is also working. it also sends mails to [EMAIL PROTECTED] on commits with diffs. https://lists.sourceforge.net/lists/listinfo/enlightenment-svn to subscribe etc. so this is up. it's ready to use - let's use it. using svn instead of cvs is childs play. i won't go into it. why not git? compromise and git is very different. all this needs now is: a. suspend of cvs activity. b. import of existing cvs tree(s) and maybe a re-org in the process, but KEEP HSITORY. i intend to remove the e17 dir and everything inside of it, flatten out to: e17/apps/ - apps/ e17/docs/ - docs/ e17/libs/ - libs/ e17/proto/ - proto/ e17/test/ - test/ we already have: devs/ - devs/ and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules apps/e_modules? why not modules/e, or external-modules/e, testing-modules/e, ... ? that's an initial import of our existing cvs modules/trees. from there on it's all svn. things can be moved and so on around. (and svn supports rename/mv). yes, it will be much easier to promote things from proto (ie: eina) and demote old cruft that lags in apps/ and libs/ to some old/unmaintained dir. c. continue development from there. i hope to get this done in the next few weeks (in august). and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, but start using trac for new feature requests, bug reports etc. i know i intend to anyway. it's just more usable (imho). it's integration with trac's wiki and svn are great. it's overall a good tool. trac is at: http://trac.enlightenment.org/e again. this won't be popular with everyone - but i think it's for the best. we've got too many dangling things to do and things put off - so these are 2 steps of many to get things organised. trac is up and ready now, so simply once svn is moved. start using it. finally :-) congrats and thanks for your time. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
Carsten Haitzler (The Rasterman) schrieb: c. continue development from there. i hope to get this done in the next few weeks (in august). So for now, I use cvs, until the switch is done, right? and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, Is there really no way to import the existing bugs on bugzilla to trac? We have many bugs (or feature request) for ewl in bugzilla, which will probably stay open for a longer timer. To use two bug tracker it'd be a pain in the ass. Also I don't want to loose the bug history (for closed bugs) as we had, when we switched from Mantis and Bug Genius to bugzilla. I've seen that there is a script to import bug reports from bugzilla to trac: http://trac.edgewall.org/wiki/TracImport Maybe that'd be an option. - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
great news! On Mon, Aug 4, 2008 at 2:19 PM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: ok. first - i know there will be unhappiness and disagreements. but i've been thinking and it's time to stop the status-quo here. some people will be pissed off, some will just be mildly unhappy, some not care, some be happy and some overjoyed. i ask to leave flamethrowers at the door. since this has been argued back and forth before and everyone has said their piece... it's nothing new. 1. we have had cvs for a long time - something in the region of a decade of using cvs... we already have an svn server - and i' have brought it up to working order: http://svn.enlightenment.org ... it was originally installed as a dependency for trac - and has been lurking, unused. i have added full dev access (there is a devs dir in svn - same devs copied from cvs, with same ssh keys and thus same access as same usernames). all existing devs have access. anonsvn is also working. it also sends mails to [EMAIL PROTECTED] on commits with diffs. https://lists.sourceforge.net/lists/listinfo/enlightenment-svn to subscribe etc. so this is up. it's ready to use - let's use it. using svn instead of cvs is childs play. i won't go into it. why not git? compromise and git is very different. all this needs now is: a. suspend of cvs activity. b. import of existing cvs tree(s) and maybe a re-org in the process, but KEEP HSITORY. i intend to remove the e17 dir and everything inside of it, flatten out to: e17/apps/ - apps/ e17/docs/ - docs/ e17/libs/ - libs/ e17/proto/ - proto/ e17/test/ - test/ we already have: devs/ - devs/ and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules that's an initial import of our existing cvs modules/trees. from there on it's all svn. things can be moved and so on around. (and svn supports rename/mv). c. continue development from there. i hope to get this done in the next few weeks (in august). and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, but start using trac for new feature requests, bug reports etc. i know i intend to anyway. it's just more usable (imho). it's integration with trac's wiki and svn are great. it's overall a good tool. trac is at: http://trac.enlightenment.org/e again. this won't be popular with everyone - but i think it's for the best. we've got too many dangling things to do and things put off - so these are 2 steps of many to get things organised. trac is up and ready now, so simply once svn is moved. start using it. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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 -- Veli Ogla Sungutay http://gui-rd.org - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, Aug 4, 2008 at 6:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules Since both Eterm and e16 are actively maintained and use some of the libs under libs, wouldn't it make sense for them to be under apps? There are still plenty of users for them and placing them under old seems like tagging them for near-term deprecation to me. If you want them under another directory, then stable makes more sense to me since they are the current stable release and do maintain stability across releases. - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, 04 Aug 2008 14:12:53 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) schrieb: c. continue development from there. i hope to get this done in the next few weeks (in august). So for now, I use cvs, until the switch is done, right? and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, Is there really no way to import the existing bugs on bugzilla to trac? We have many bugs (or feature request) for ewl in bugzilla, which will probably stay open for a longer timer. To use two bug tracker it'd be a pain in the ass. Also I don't want to loose the bug history (for closed bugs) as we had, when we switched from Mantis and Bug Genius to bugzilla. I've seen that there is a script to import bug reports from bugzilla to trac: http://trac.edgewall.org/wiki/TracImport Maybe that'd be an option. there is.. i just didn't feel like filling up trac with all the old bugzilla junk... and there is a lot of stuff there that will need much cleaning up/munging to go into trac. this is a good opportunity to start afresh and cleanly (imho). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, 4 Aug 2008 08:05:33 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 6:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules Since both Eterm and e16 are actively maintained and use some of the libs under libs, wouldn't it make sense for them to be under apps? There are still plenty of users for them and placing them under old seems like tagging them for near-term deprecation to me. well - eterm is pretty much static. it does get the odd commit. e16 - yes. active, but it is the predecessor to e17 and i'd like to move things into an according place. something dead/old should go there - including old libs and apps that are basically dead or non-actively worked on. If you want them under another directory, then stable makes more sense to me since they are the current stable release and do maintain stability across releases. doesn't much matter - but i'd like to group them together. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] Eina
On Mon, Aug 4, 2008 at 8:02 AM, Nathan Ingersoll [EMAIL PROTECTED] wrote: Before this turns completely into another license flame-war. Let's step back and look at this from a more practical standpoint. I'm going to list the set of arguments mentioned as to why we need LGPL, since that is the point being argued, along with questions that would need to be answered for this change to make sense. Argument 1. Our community has failed to grow because of our choice of license. Question 1. What proof exists that choice of license has repelled more people than it has attracted? Counter 1. Most users don't weigh choice of license into their decision to use a product. Even among open source users they are happy if the software uses an OSI approved license. It's very common that users don't even realize E is BSD. Users don't care about license. That's right. It only affect the community of developpers and people contributing back to the project. Counter 2. E has attracted a large number of users over the years and many of them have moved on to other things. Of the users that have left the project, the choice of license is never brought up as the reason. It is almost always around the lack of progress, the need for better integration with their applications, or finding another environment they prefer over E. Among our developers it's usually because other obligations require too much time to contribute to the project any longer, or simply a change in priorities in their lives. In the list, the lack of progress is mainly due to the difficulty we have to gain more contribution. That's in my opinion partially due to the license. Argument 2. Attracting more companies will grow our community. Question 1. Is expanded business use the best way to grow our community? Counter 1. In most successful open source projects the support from the business community comes after the user base has reached a self-sustaining level with a reasonable growth rate. While E has maintained a self-sustaining level over the years, we have a stagnant growth rate. For the last few years we have a pretty consistent incoming developer base of approximately the same size as the developers that are leaving the project or cutting back their time spent on it. So in your opinion the success of GNOME and KDE as nothing to do with the fact that many company are backing them since almost the beginning. And yes, in 10 years, the Enlightenment project failed to increase the size of it's developper base. Contributions are not increasing faster and faster, and the fact that the license doesn't create a contribution loop as nothing to do with this fact. Counter 2. While businesses make valuable contributions to help polish projects and develop key features, they are not usually the driving force behind successful projects. In most cases, the projects that have become too corporate have seen declining community contributions. The extreme case of this is code which was started by a company and that company has basically been doing all development, just in the open. This can lead to projects that are too easily swayed by corporate considerations or changes in strategy. MySQL is a good example of this scenario. As you are making general statements, could you make them on GNOME and KDE as they are more in the same field as we are. Argument 3. Companies can legally use and change our code without giving back. Question 1. How does LGPL prevent this from happening? Counter 1. The LGPL prevents this only if they make changes directly within the code and distribute the end product. Since linking is specifically allowed, a company can write a thin wrapper which extends the lib with the functionality they want and just link in the existing code. Yes, thin wrapper are a solution, but how much people are willing to do so for just a few line. It will be easier for them, to just put the source somewhere to follow the license than do the necessary amount of stuff needed by a wrapper. With the BSD license, they just don't care. Nothing force them to do the small effort to give back, so why did they need to care and do it ? Counter 2. There is also the possibility of going the other direction, as they could export the functionality that they want as a lib and re-distribute the small changes within our code that access their lib. The same argument came here too. How many people did this for GTK ? None I know about, but they are many patch around that didn't get their way in the GTK code base. This patch could get integrated or not, but they are contributing back to the project itself and influence the futur of GTK. Counter 3. The binary from the modified code is not directly distributed to end users. For instance with a web service or other client-server model, there is no requirement in most OSI approved license that these modifications be distributed. Does it cover our EFL use case ? Perhaps LGPLv3 can solve
[E-devel] Nightly build log for E17 on 2008-08-04 07:11:53 -0700
Build log for Enlightenment DR 0.17 on 2008-08-04 07:11:53 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - 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] RFC: embryo release in 2 weeks
On Mon, 2008-08-04 at 08:57 -0300, Gustavo Sverzut Barbieri wrote: On Mon, Aug 4, 2008 at 5:50 AM, Cedric BAIL [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. :( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. Excellent to know, so I remove my JS arguments altogether, Lua we go! (but as davemds said later, I'd keep embryo for some time). Are we going to integrate lua 5.1 or an earlier version into edje? If it is 5.1, are we going to create an edje specific module (I don't know how one exposes an API in earlier versions) ? - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
Carsten Haitzler (The Rasterman) schrieb: On Mon, 04 Aug 2008 14:12:53 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) schrieb: c. continue development from there. i hope to get this done in the next few weeks (in august). So for now, I use cvs, until the switch is done, right? and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, Is there really no way to import the existing bugs on bugzilla to trac? We have many bugs (or feature request) for ewl in bugzilla, which will probably stay open for a longer timer. To use two bug tracker it'd be a pain in the ass. Also I don't want to loose the bug history (for closed bugs) as we had, when we switched from Mantis and Bug Genius to bugzilla. I've seen that there is a script to import bug reports from bugzilla to trac: http://trac.edgewall.org/wiki/TracImport Maybe that'd be an option. there is.. i just didn't feel like filling up trac with all the old bugzilla junk... and there is a lot of stuff there that will need much cleaning up/munging to go into trac. this is a good opportunity to start afresh and cleanly (imho). I'm not talking here about a handful of bug reports. We have 75 open bugs for ewl many of them with examples to reproduce them, with initial patches and long discussions, and we have a history of 148 resolved bugs, which i don't want to loose, either. - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, 4 Aug 2008 23:23:11 +1000 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 4 Aug 2008 08:05:33 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 6:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules Since both Eterm and e16 are actively maintained and use some of the libs under libs, wouldn't it make sense for them to be under apps? There are still plenty of users for them and placing them under old seems like tagging them for near-term deprecation to me. well - eterm is pretty much static. it does get the odd commit. e16 - yes. active, but it is the predecessor to e17 and i'd like to move things into an according place. something dead/old should go there - including old libs and apps that are basically dead or non-actively worked on. Then perhaps large amounts of misc/ should go into old/? signature.asc Description: PGP signature - 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
Le lundi 4 août 2008, Carsten Haitzler a écrit : On Sun, 3 Aug 2008 16:49:05 +0200 Raoul [EMAIL PROTECTED] babbled: Here is my feedback about Edje. aaah raoul! - btw.. calaos is fantastic - what you've done is great and you ahve heavily used efl... so it's one of the prime examples here and your input is very important (as is that of any other major users of efl, in addition to what we have in CVS). Héhé, thanks. but with some powerfull libs, that's easy... We used a lot of embryo code in the calaos project. Most of the time it is just to set/get some simple vars for more control on states of an object. This is ok, works great, and embryo is designed to do that. About the swith to another scripting language, i will just say 2 things. This is ok for me, i will do the conversion in my edj (perhaps i don't have anything to do, because embryo and lua syntax are close). It would not be a lot of work for me. Lua would be a good choice, it's a very small VM, and it will run smoothly on embedded devices. ok. so you would live with a transition over. But, I think there are more important issues with edje at this time. Writing edc using macros are a real pain and a waste of time. Macros are hard to write, hard to debug, hard to maintain and unreadable. We need a better way to write generic object (edje script only?). exactly! this was what was prompting my exploration into alternatives. i started writing the script_only code for edje... it works... but it uses embryo. as i was doing it i realised just how heavy the calls going into and out of the embryo vm were - i made changes to make that lighter, but then realised, to make bindings easy... i was re-creating a lot of glue (converting pointers to object id's back and forth for example) and being able to have dynamic datatypes without going thru the heavy get/set api. (eg just an array u can alloc of object's or a list etc.) that is native to the language. this is where embryo stumbles. it has no heap of its own to alloc to - so all allocs happen via a binding... even for simple temporary data for just doing intermediate work... and it was looking really cumbersome to do, so i was beginning to think it may be a good idea to look further into other solutions... thus the lua thing came up. before embryo was used, lua was a close second - and ferite was definitely on the list too. Edje is also missing some more complex objects like lists. For now, any lists have to be done in the C side, it freezes a bit the theming capabilities. Having the possibilitie to extend edje by exporting a smart-object (list or any super-cool-smart-object) with its properties and capabilities to edje would be awsome. yup. this is also planned to be added. layout objects in edje where you can just pack/unpack multiple children and the layout object lays them out in a vertical/horizontal list, maybe a horizontal list with line-wrap, and for that matter, all sorts of other arrangements. the reason edje didn't get this on day 0 was that i wanted these layouts to be able to do all sorts of fancy things - if designers wanted to - eg a spiral, a curved line of items that resize and fade in and how as they walk along the list etc. the problem was in how to expose such a layout engine to a designer and make it easy to use yet powerful. I would be more than happy to see all of these stuffs in edje :) For example, in the application code, you tell edje to load a LIST smart-object with some properties, and then edje can use it like a standard parts in the edc. In the part definition, you can change the properties of the LIST, like enable/disable kinetic scrolling, horizontal/vertical scrolling, ... Such a feature could really help designers to be more productive in writing edc, and give them much more power. yup. As I said, for now writing edc is a painfull task. -- Raoul Hecky Calaos -- Raoul Hecky - 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] Eina
Jorge Luis Zapata Muga wrote: Hi all, as you all (most) know, eina has hit proto cvs. I think several things have to be explained, references to eina's license, code and so have appeared on different threads and honestly following them all is very complicated and is also hard to actually decide something, so it might be good if at some moment, someone can make a summary of several opinions and just do a poll and decide on it. Anyway, here is my summary: Objective: Eina's original objective was to settle down the long-time discussion about multiple data types, mainly ecore's and evas', it was an attempt that, from what i've seen, several developers have agreed and have a good will on this library; even the ecore's data types supporter (eina's is currently based around evas data types). It has several subsystems in a very similar way to what ecore has, but the main reason to not place ecore on the bottom of the software dependency stack was because not every library built around our data types wants to be loopized with ecore's main loop implementation, but be some kind of agnostic to ecore, so gtk / qt / whatever can use this libraries an fit their own loop manager on top of this low level library. Evas is an example of such a thing (there are others), and no, ecore-evas current double dependency is not the main problem eina wants to solve, not even the original problem it wanted to solve. If you place the efl stack, eina will be at the bottom, ecore on top of it and so other libraries/apps that *need* some kind of main loop handling, it can be summarized as pull approach libraries you pull the state from it, instead of evas (and others libraries) where you push the state (evas_render). License As most of the code on efl-research project (and most of *my* code) it does not have COPYING file, it was left out on purpose, basically to be able to discuss this license issue with e developers. We all have already argued about licensing and there are several respectable and contrary point of views. I, as the original author of this library, even if some of the code was taken from evas or ecore, wanted to license the library as LGPL; but as i have already stated, this new license has several considerations, *please* don't start a license arguments, the other thread is for that, this one is to decide: 1. Relicensing eina as LGPL is possible and *does not* go against Evas or Ecore license, BSD allows that as long as the third (author) clause is respected and so it will be (in case eina's license finally gets set to LGPL) 2. What will be the reaction from developers that want BSD license? from what i've deduced on IRC and ML, several of this developers *won't* contribute to this library if it is not BSD, (please those developers that think that this is point is for them, confirm or deny this). In my opinion the current state of e developers is too small to actually divide it based on the license they prefer; and of course that argument imposes the license the library can be. So, the main question on this point is: if it is LGPL are you going to contribute to it? and, if it is LGPL are you going to *link against this library? ps: i would like to discuss several eina's subsytems, but looks like the license has to be solved first, so let's get it done, so we can focus on the code. Best regards, turran Not that I think my opinion is particularly relevant or that it will help in one direction or the other, but I'll just state it anyway: I think there should be One License for The Enlightenment Project. I think the One License rule should be enforced strictly. If people have code they don't want to place under The License for The Enlightenment Project they should take it elsewhere. I'd prefer The Licence to be BSD. This means that if any part of The Enlightenment Project remains under BSD I will object to changing the license for any other part away from BSD or adding new sub-projects with a different license. My main reason is that I think the current situation where it is possible to move/copy code between apps and libs without having to worry about infection and license differences is good. If it is possible to obtain no objections to switching ALL of The Enlightenment Project to LGPL, ok then let's switch. However, I don't think there is any chance this is going to happen. I think it would be *really* nice soon to put an end to all this license talk for some time to come. /Kim - 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
Re: [E-devel] moving things along - cvs - svn and bugs (bugzilla-trac)
On Tue, 2008-08-05 at 01:27 +1000, David Seikel wrote: On Mon, 4 Aug 2008 23:23:11 +1000 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 4 Aug 2008 08:05:33 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 6:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules Since both Eterm and e16 are actively maintained and use some of the libs under libs, wouldn't it make sense for them to be under apps? There are still plenty of users for them and placing them under old seems like tagging them for near-term deprecation to me. well - eterm is pretty much static. it does get the odd commit. e16 - yes. active, but it is the predecessor to e17 and i'd like to move things into an according place. something dead/old should go there - including old libs and apps that are basically dead or non-actively worked on. Then perhaps large amounts of misc/ should go into old/? - 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 is there anything under misc that is currently usable? - 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] Eina
On Mon, 04 Aug 2008 17:44:22 +0200 Kim Woelders [EMAIL PROTECTED] wrote: Not that I think my opinion is particularly relevant or that it will help in one direction or the other, but I'll just state it anyway: I think there should be One License for The Enlightenment Project. I think the One License rule should be enforced strictly. If people have code they don't want to place under The License for The Enlightenment Project they should take it elsewhere. One True License makes sense for a collection of libraries like EFL, so I agree. I'd prefer The Licence to be BSD. I really don't care which it is. I contribute code to open source projects I want to, regardless of particular licence used. If it is possible to obtain no objections to switching ALL of The Enlightenment Project to LGPL, ok then let's switch. However, I don't think there is any chance this is going to happen. Let me state again, it will be impossible to change license. One of two things MUST happen to change - A) Every single author that contributed code must agree to the change. There is ample evidence from these discussions that this simply will NEVER happen. Too many people are sticking to their guns about sticking with the current license. No amount of argument will change their minds. On top of that, the off list email I mentioned before that tried to get opinions from all those authors proved one thing, we cannot track them all down anyway. B) Given that A) is impossible, someone has to go through the entire codebase and audit it for code that cannot be relicensed and replace it with code that can. This is not going to make our small number of active developers more productive. It will be a huge effort, and will simply not be worth it. I think it would be *really* nice soon to put an end to all this license talk for some time to come. Yes please. Stop wasting our time with copious arguments over something that will either not be possible, or such a big effort that it is counter productive. Let's spend our valuable time on coding. /me seriously considers telling his email client to ignore the license flame wars. signature.asc Description: PGP signature - 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] Eina
I completely agree with you. Just one note: the CORE* libraries and the main product (e17 itself) should be licensed under one license. Currently it's BSD, so when developing a new core lib (in this case it's Eina) it should be also BSD. If someone wants to develop some app or some lib that is not of the core EFL - he/she should feel free to license it whatever he/she likes. There are many arguments to support this and they all are already written by others. It's now clear that there can't be a smooth move to another license - there are (too many, active, respected, with big contributions to the project) developers who want to keep their code BSD-licensed. There was too much buzz and discussion on this topic, it is now clear that every core library you guys create from now on should be BSD-licensed. So carry on, write the damn thing and let's rock on :-) *By mine (and hopefully others) definition the core libs are those who E17 and Ewl/Etk depend (not optionally) on. Not that I think my opinion is particularly relevant or that it will help in one direction or the other, but I'll just state it anyway: I think there should be One License for The Enlightenment Project. I think the One License rule should be enforced strictly. If people have code they don't want to place under The License for The Enlightenment Project they should take it elsewhere. I'd prefer The Licence to be BSD. This means that if any part of The Enlightenment Project remains under BSD I will object to changing the license for any other part away from BSD or adding new sub-projects with a different license. My main reason is that I think the current situation where it is possible to move/copy code between apps and libs without having to worry about infection and license differences is good. If it is possible to obtain no objections to switching ALL of The Enlightenment Project to LGPL, ok then let's switch. However, I don't think there is any chance this is going to happen. I think it would be *really* nice soon to put an end to all this license talk for some time to come. /Kim - 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 -- Luchezar P. Petkov http://luchko.net - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, 04 Aug 2008 18:45:42 +0300 Viktor Kojouharov [EMAIL PROTECTED] wrote: On Tue, 2008-08-05 at 01:27 +1000, David Seikel wrote: On Mon, 4 Aug 2008 23:23:11 +1000 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 4 Aug 2008 08:05:33 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 6:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules Since both Eterm and e16 are actively maintained and use some of the libs under libs, wouldn't it make sense for them to be under apps? There are still plenty of users for them and placing them under old seems like tagging them for near-term deprecation to me. well - eterm is pretty much static. it does get the odd commit. e16 - yes. active, but it is the predecessor to e17 and i'd like to move things into an according place. something dead/old should go there - including old libs and apps that are basically dead or non-actively worked on. Then perhaps large amounts of misc/ should go into old/? is there anything under misc that is currently usable? Yes, some of it is even maintained. signature.asc Description: PGP signature - 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] Eina
I want to point out that as the person asking for the change, the burden of proof is on you. Therefore, look at your statements below and show us solid proof behind any of them. For every example you give of an open source project that supposedly succeeded because of it's license being GPL/LGPL, you can find others that have comparable success with a different license. You also treat this discussion with the founding principle that license is the only variable in project success, which is neither true or a reasonable basis to start from. On Mon, Aug 4, 2008 at 8:32 AM, Cedric BAIL [EMAIL PROTECTED] wrote: Users don't care about license. That's right. It only affect the community of developpers and people contributing back to the project. You say that developers make the difference and users don't care, but where do you think your developers come from in an open source community? Most of the active developers in the history of E have come from people that started as users. There are a few exceptions of people that were paid explicitly to do some work and had not previously used E. If you attract a growing user base you attract more potential developers. Where are our users coming from these days? Every time E makes some headlines, we see a sudden influx of users and usually get a few patches from them. Regular attention to a project is what drives a steady influx of users and developers. In the list, the lack of progress is mainly due to the difficulty we have to gain more contribution. That's in my opinion partially due to the license. Ok, so you've stated an opinion with no backing evidence... So in your opinion the success of GNOME and KDE as nothing to do with the fact that many company are backing them since almost the beginning. And yes, in 10 years, the Enlightenment project failed to increase the size of it's developper base. Contributions are not increasing faster and faster, and the fact that the license doesn't create a contribution loop as nothing to do with this fact. KDE and GNOME are not the same thing, they were desktop environments with supporting libs long before E went that direction. In fact, I already mentioned this history in an earlier thread and pointed out that people in E helped develop the base of GNOME. E is the relative new comer in the desktop area where there are already two major established players. We have not even made a release in that area while they're well-established with many past releases and regular media attention. Their success was helped by companies contributing to them, but companies contribute to them because they have an active user base and community. Also, E had companies paying for work on it from some of it's earlier days as well, but it was done as part of GNOME originally. Later it had paid development work done on the basis of a desktop shell, but there are very little remnants of that work remaining in the code base. Lastly, you're right and wrong about failing to increase the size of the developer base. We've had peaks and valleys throughout the last 10 years. There are times when we've had a steadily growing number of developers, and then a sudden increase in attrition. The influx occurred when E had some media exposure such as a magazine article or when yellow dog started shipping with it. Usually we lose developers around these types of discussions, and not the people actually making the arguments, but bystanders that feel the project has become too political. Counter 2. While businesses make valuable contributions to help polish projects and develop key features, they are not usually the driving force behind successful projects. In most cases, the projects that have become too corporate have seen declining community contributions. The extreme case of this is code which was started by a company and that company has basically been doing all development, just in the open. This can lead to projects that are too easily swayed by corporate considerations or changes in strategy. MySQL is a good example of this scenario. As you are making general statements, could you make them on GNOME and KDE as they are more in the same field as we are. Sure, both GNOME and KDE have contributions from a variety of companies and have a healthy eco-system of non-paid contributors too. You can't rely companies to be your benefactor to reach your goals, but they can be strong community members. Argument 3. Companies can legally use and change our code without giving back. Question 1. How does LGPL prevent this from happening? Counter 1. The LGPL prevents this only if they make changes directly within the code and distribute the end product. Since linking is specifically allowed, a company can write a thin wrapper which extends the lib with the functionality they want and just link in the existing code. Yes, thin wrapper are a solution, but how much people are willing to do so for just a few line. It will be easier for
Re: [E-devel] moving things along - cvs - svn and bugs (bugzilla-trac)
do it up. On Mon, Aug 4, 2008 at 8:08 AM, Sthithaprajna Garapaty [EMAIL PROTECTED] wrote: May I also suggest we also move to a single wiki (Trac) and get rid of MediaWiki http://trac.edgewall.org/wiki/TracWikiConversion On Mon, Aug 4, 2008 at 10:44 AM, Peter Wehrfritz [EMAIL PROTECTED] wrote: Carsten Haitzler (The Rasterman) schrieb: On Mon, 04 Aug 2008 14:12:53 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) schrieb: c. continue development from there. i hope to get this done in the next few weeks (in august). So for now, I use cvs, until the switch is done, right? and 2. trac (bugzilla alternative). this integrates with svn - ticket numbers in log commits will have links back to their tickets in trac. it even allows wiki formatting in svn logs. it's simpler than bugzilla and imho easier to use, but has enough to work with. it support multiple sub-projects (already several in trac) and milestones and releases. it does the job. i don't want to import existing bugzilla bug items... so keep bugzilla for the old stuff, Is there really no way to import the existing bugs on bugzilla to trac? We have many bugs (or feature request) for ewl in bugzilla, which will probably stay open for a longer timer. To use two bug tracker it'd be a pain in the ass. Also I don't want to loose the bug history (for closed bugs) as we had, when we switched from Mantis and Bug Genius to bugzilla. I've seen that there is a script to import bug reports from bugzilla to trac: http://trac.edgewall.org/wiki/TracImport Maybe that'd be an option. there is.. i just didn't feel like filling up trac with all the old bugzilla junk... and there is a lot of stuff there that will need much cleaning up/munging to go into trac. this is a good opportunity to start afresh and cleanly (imho). I'm not talking here about a handful of bug reports. We have 75 open bugs for ewl many of them with examples to reproduce them, with initial patches and long discussions, and we have a history of 148 resolved bugs, which i don't want to loose, either. - 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 - 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 - 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] [e-users] [website] What would you like to see on the new site?
whoops messed up on the link it's http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png On Mon, Aug 4, 2008 at 12:17 AM, Toma [EMAIL PROTECTED] wrote: On 04/08/2008, Ian Caldwell [EMAIL PROTECTED] wrote: absolutely and I believe in redoing the navigation would involve redoing the site. If anyone would like to share any other mock ups other than mekius go ahead. I personally like simple site designs like this: http://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png(flamehttp://fc06.deviantart.com/fs30/i/2008/126/3/0/Inkscape_Site_develfront_by_duckgoesoink.png%28flame me if you want) minus the fact that I think the inkscape in brief section should be just a wider news section and take the little news box off the side. but I like designs like that because they list all the links to the different web software. Songbird does this on their site too but their site is a little too busy http://getsongbird.com/ just my thoughts I like the Inkscape mockup. Looks professional and has all the content at a place thats very easy to see. The icons help too for those that dont know english and cant be bothered switching to their language translation. Songbird one give me the idea of using some cool ajax for the icons. Since EFL and all can do cool animations, maybe something neat like that could make its way into the website? Toma On Sun, Aug 3, 2008 at 9:06 PM, dan sinclair [EMAIL PROTECTED] wrote: On 3-Aug-08, at 10:07 PM, Nick Hughart wrote: Carsten Haitzler (The Rasterman) wrote: On Fri, 01 Aug 2008 13:33:34 -0500 Nick Hughart [EMAIL PROTECTED] babbled: Ian Caldwell wrote: Yup, I'd like to eliminate submenus completely One navigation on all pages that has links to pretty much everything. The goal of the new site is make it a lot more usable. With regularly updated news, and a lot of static content around it. This is bad design imo, it leads to overload. Having to dig through a ton of links to find the one you want is crazy, it's best to be able to filter towards your goal IMO. Much easier to filter then to try and find a link among many that sounds like what you want. This is how my brain works anyway. we don't need some new navigation system... we need to simplify content, only put up what we absolutely need on the e.org brochure site (it's meant to be a simple couple of pages brochure/flier like set of pages with just the minimum needed to find out what e is, who is involved, how/where to get it). the other bits (trac/bugzilla, wiki, docs etc. etc.) are what is intended for large-scale documentation and info - and those (the wiki especially) is READILY accessible to people to edit. Yes, I realize this, most of the links in the submenus will just point to the wiki/tracker/etc. But people found it hard to even find these things on the current site. So it would be nice to point them to where they need to look instead of them having to decode links that don't necessarily match anything they are looking for. So the changes to navigation are nothing stellar, just reorganizing the menu and making the submenu a little more visible so people immediately see things to click on. At least this is what I did with my mockup, haven't seen anyone else come forward with anything yet. I'm with Mekius. The number one complaint that I get about the website is that the navigation sucks. If we can do something to make it easier for people to find stuff then it's a win. 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 - 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] Eina
In all honesty, I don't think a license makes or breaks a project.. unless of course it's closed source. I don't think you're realizing how much crap has to be done to change licenses for little to no reason. On Mon, Aug 4, 2008 at 9:59 AM, Nathan Ingersoll [EMAIL PROTECTED] wrote: I want to point out that as the person asking for the change, the burden of proof is on you. Therefore, look at your statements below and show us solid proof behind any of them. For every example you give of an open source project that supposedly succeeded because of it's license being GPL/LGPL, you can find others that have comparable success with a different license. You also treat this discussion with the founding principle that license is the only variable in project success, which is neither true or a reasonable basis to start from. On Mon, Aug 4, 2008 at 8:32 AM, Cedric BAIL [EMAIL PROTECTED] wrote: Users don't care about license. That's right. It only affect the community of developpers and people contributing back to the project. You say that developers make the difference and users don't care, but where do you think your developers come from in an open source community? Most of the active developers in the history of E have come from people that started as users. There are a few exceptions of people that were paid explicitly to do some work and had not previously used E. If you attract a growing user base you attract more potential developers. Where are our users coming from these days? Every time E makes some headlines, we see a sudden influx of users and usually get a few patches from them. Regular attention to a project is what drives a steady influx of users and developers. In the list, the lack of progress is mainly due to the difficulty we have to gain more contribution. That's in my opinion partially due to the license. Ok, so you've stated an opinion with no backing evidence... So in your opinion the success of GNOME and KDE as nothing to do with the fact that many company are backing them since almost the beginning. And yes, in 10 years, the Enlightenment project failed to increase the size of it's developper base. Contributions are not increasing faster and faster, and the fact that the license doesn't create a contribution loop as nothing to do with this fact. KDE and GNOME are not the same thing, they were desktop environments with supporting libs long before E went that direction. In fact, I already mentioned this history in an earlier thread and pointed out that people in E helped develop the base of GNOME. E is the relative new comer in the desktop area where there are already two major established players. We have not even made a release in that area while they're well-established with many past releases and regular media attention. Their success was helped by companies contributing to them, but companies contribute to them because they have an active user base and community. Also, E had companies paying for work on it from some of it's earlier days as well, but it was done as part of GNOME originally. Later it had paid development work done on the basis of a desktop shell, but there are very little remnants of that work remaining in the code base. Lastly, you're right and wrong about failing to increase the size of the developer base. We've had peaks and valleys throughout the last 10 years. There are times when we've had a steadily growing number of developers, and then a sudden increase in attrition. The influx occurred when E had some media exposure such as a magazine article or when yellow dog started shipping with it. Usually we lose developers around these types of discussions, and not the people actually making the arguments, but bystanders that feel the project has become too political. Counter 2. While businesses make valuable contributions to help polish projects and develop key features, they are not usually the driving force behind successful projects. In most cases, the projects that have become too corporate have seen declining community contributions. The extreme case of this is code which was started by a company and that company has basically been doing all development, just in the open. This can lead to projects that are too easily swayed by corporate considerations or changes in strategy. MySQL is a good example of this scenario. As you are making general statements, could you make them on GNOME and KDE as they are more in the same field as we are. Sure, both GNOME and KDE have contributions from a variety of companies and have a healthy eco-system of non-paid contributors too. You can't rely companies to be your benefactor to reach your goals, but they can be strong community members. Argument 3. Companies can legally use and change our code without giving back. Question 1. How does LGPL prevent this from happening? Counter 1. The LGPL prevents this only if
[E-devel] [ANN] QEdje 0.1
Hello, We at OpenBossa (opensource stream of INdT) are pleased to announce the first version of QEdje, a library that enables the use of Edje components in Qt4. I guess I don't need to describe Edje for you :-), so I'm skipping that. This is experimental code, some features are not implemented yet, scripting is one of them, but we are aiming to be fully compatible with libedje. Some of the developers have written about it, see http://atdrez.wordpress.com/2008/07/19/qedje/ http://labs.morpheuz.eng.br/blog/01/08/2008/qedje-init/ The project website is http://dev.openbossa.org/qedje and there's also a mailing list, more information at http://groups.google.com/group/qedje The developers are also most of the time available at #edevelop channel. -- Caio Marcelo de Oliveira Filho OpenBossa Labs - INdT - 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] [ANN] QEdje 0.1
Cool, any change of geting a GEdje (GTK)? I mean, to use with Gambas, for example? Regards. On Aug 4, 2008, at 2:19 PM, Caio Oliveira wrote: Hello, We at OpenBossa (opensource stream of INdT) are pleased to announce the first version of QEdje, a library that enables the use of Edje components in Qt4. I guess I don't need to describe Edje for you :-), so I'm skipping that. This is experimental code, some features are not implemented yet, scripting is one of them, but we are aiming to be fully compatible with libedje. Some of the developers have written about it, see http://atdrez.wordpress.com/2008/07/19/qedje/ http://labs.morpheuz.eng.br/blog/01/08/2008/qedje-init/ The project website is http://dev.openbossa.org/qedje and there's also a mailing list, more information at http://groups.google.com/group/qedje The developers are also most of the time available at #edevelop channel. -- Caio Marcelo de Oliveira Filho OpenBossa Labs - INdT - 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 - 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] [ANN] QEdje 0.1
Cool, any change of geting a GEdje (GTK)? I mean, to use with Gambas, for example? Hi. Our focus today is extending and optimizing QEdje (Qt) so currently there're no plans to develop something as a GEdje. Best regards, -- Eduardo M. Fleury OpenBossa labs - INdT - 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] RFC: embryo release in 2 weeks
On Mon, 04 Aug 2008 17:16:47 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: On Mon, 2008-08-04 at 08:57 -0300, Gustavo Sverzut Barbieri wrote: On Mon, Aug 4, 2008 at 5:50 AM, Cedric BAIL [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 2:25 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 02:43:33 +0300 Viktor Kojouharov [EMAIL PROTECTED] babbled: Rhino is java based, so that's out. Then we have SpiderMonkey, which is currently used by gecko1.9. That's not as fast as webkit's engine. Then there's tamarin, which is practically future proof, with its support for ES4. However, it's not complete. I don't know of any other engines out there. hmmm wel then it spidermonkey or... nothing. and spidermonkey is pretty fat... it's api is pretty big... :/ quick look.. not smelling positive. : ( I am playing with spidermonkey since some time now and trust me you want to use lua for edje. It's smaller, easier to integrate and fit the need of edje. It's perhaps not a good solution for big apps, but for small script it should be perfect. And in my opinion, it's a matter of a few days to switch to lua in edje and we should do it sooner than latter. I would really like to see this before the end of august and looking at edje, sounds like a really straight forward jobs. Excellent to know, so I remove my JS arguments altogether, Lua we go! (but as davemds said later, I'd keep embryo for some time). Are we going to integrate lua 5.1 or an earlier version into edje? If it is 5.1, are we going to create an edje specific module (I don't know how one exposes an API in earlier versions) ? 5.1 as it's the current lua release - or one of the latest, even then later versions (of lua) unless they break api should just work. as for module - no. just a new .edc script section to throw the lua code into. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Tue, 5 Aug 2008 01:27:32 +1000 David Seikel [EMAIL PROTECTED] babbled: On Mon, 4 Aug 2008 23:23:11 +1000 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 4 Aug 2008 08:05:33 -0500 Nathan Ingersoll [EMAIL PROTECTED] babbled: On Mon, Aug 4, 2008 at 6:19 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: and i want to put in other cvs modules: misc/ - misc/ eterm/ - old/eterm/ web/www - www/ e16/ - old/e16/ e_modules/ - apps/e_modules Since both Eterm and e16 are actively maintained and use some of the libs under libs, wouldn't it make sense for them to be under apps? There are still plenty of users for them and placing them under old seems like tagging them for near-term deprecation to me. well - eterm is pretty much static. it does get the odd commit. e16 - yes. active, but it is the predecessor to e17 and i'd like to move things into an according place. something dead/old should go there - including old libs and apps that are basically dead or non-actively worked on. Then perhaps large amounts of misc/ should go into old/? yup. i was going to svn move things later around the repo. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Mon, 04 Aug 2008 16:44:08 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: I'm not talking here about a handful of bug reports. We have 75 open bugs for ewl many of them with examples to reproduce them, with initial patches and long discussions, and we have a history of 148 resolved bugs, which i don't want to loose, either. i can look at it - chances are though an import will make a right royal mess :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
[E-devel] E_Hal compilation problem
Hi all
I have problem using E_Hal (adn/or E_DBus) in an e module:
If I use: #include E_DBus.h
I always get:
In file included from /usr/local/include/E_Hal.h:3,
from e_mod_main.c:3:
/usr/local/include/E_DBus.h:42: error: expected ‘{’ before ‘void’
/usr/local/include/E_DBus.h:42: error: two or more data types in declaration
specifiers
the line 42 of E_DBus.h is:
typedef struct E_DBus_Interface E_DBus_Interface;
Is right to link against E_dbus and E_hal in the module autotool? or
is e17 that link against that libs?
Someone has an idea? i'm getting creazy and is probably a stipid thing :(
Thanks
Dave
-
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] moving things along - cvs - svn and bugs (bugzilla-trac)
After a discussion in IRC we ended up with a solution. We will convert both Mediawiki and Bugzilla's content and throw it in Trac using scripts that were made exactly for this purpose (by the Trac team). Hopefully without much problems. I will also help with the rest of the by-hand work with the filling/organizing the content. The plan is to use Trac as both wiki (for both dev and user docs) and a bug tracker and integrate it with the new site layout, its gonna be very clean, simple and useful. I hope that nobody will argue this time.. and that we don't actually need yet another thread to discuss this. On Tue, Aug 5, 2008 at 1:43 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 16:44:08 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: I'm not talking here about a handful of bug reports. We have 75 open bugs for ewl many of them with examples to reproduce them, with initial patches and long discussions, and we have a history of 148 resolved bugs, which i don't want to loose, either. i can look at it - chances are though an import will make a right royal mess :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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 -- Luchezar P. Petkov http://luchko.net - 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] RFC: embryo release in 2 weeks
to play with it first... the question is.. embryo - keep for compatibility
(after the lua change) or throw out? i would keep it anyway while adding
lua...
but then.. remove or not? i am listening to those using embryo right now.
Well, until Lua is in place I see no problem in keeping Embryo code
also working if causes no harm, using some mechanism like the proposed
in other thread: having annotations for the script tag, and defaults
it to embryo. After Lua is ok, we can evaluate how much Embryo is
still needed, having the option of phasing out it slowly.. (changing
the default script {} to go Lua first, and then removing the
annotations).
Cheers,
Caio Marcelo
-
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] RFC: embryo release in 2 weeks
On Mon, 4 Aug 2008 21:02:38 -0300 Caio Marcelo [EMAIL PROTECTED] babbled:
to play with it first... the question is.. embryo - keep for compatibility
(after the lua change) or throw out? i would keep it anyway while adding
lua... but then.. remove or not? i am listening to those using embryo right
now.
Well, until Lua is in place I see no problem in keeping Embryo code
also working if causes no harm, using some mechanism like the proposed
in other thread: having annotations for the script tag, and defaults
it to embryo. After Lua is ok, we can evaluate how much Embryo is
still needed, having the option of phasing out it slowly.. (changing
the default script {} to go Lua first, and then removing the
annotations).
oh absolutely - the question more is.. to release edje 1.0 - do we remove
embryo after lua is up and fully functional (equivalent to embryo or better)
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
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] moving things along - cvs - svn and bugs (bugzilla-trac)
On Tue, 5 Aug 2008 02:51:06 +0300 Luchezar Petkov [EMAIL PROTECTED] babbled: sounds like a good simplification :) After a discussion in IRC we ended up with a solution. We will convert both Mediawiki and Bugzilla's content and throw it in Trac using scripts that were made exactly for this purpose (by the Trac team). Hopefully without much problems. I will also help with the rest of the by-hand work with the filling/organizing the content. The plan is to use Trac as both wiki (for both dev and user docs) and a bug tracker and integrate it with the new site layout, its gonna be very clean, simple and useful. I hope that nobody will argue this time.. and that we don't actually need yet another thread to discuss this. On Tue, Aug 5, 2008 at 1:43 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Mon, 04 Aug 2008 16:44:08 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: I'm not talking here about a handful of bug reports. We have 75 open bugs for ewl many of them with examples to reproduce them, with initial patches and long discussions, and we have a history of 148 resolved bugs, which i don't want to loose, either. i can look at it - chances are though an import will make a right royal mess :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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 -- Luchezar P. Petkov http://luchko.net -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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] RFC: embryo release in 2 weeks
On Tue, 2008-08-05 at 10:07 +1000, Carsten Haitzler wrote:
On Mon, 4 Aug 2008 21:02:38 -0300 Caio Marcelo [EMAIL PROTECTED] babbled:
to play with it first... the question is.. embryo - keep for compatibility
(after the lua change) or throw out? i would keep it anyway while adding
lua... but then.. remove or not? i am listening to those using embryo
right
now.
Well, until Lua is in place I see no problem in keeping Embryo code
also working if causes no harm, using some mechanism like the proposed
in other thread: having annotations for the script tag, and defaults
it to embryo. After Lua is ok, we can evaluate how much Embryo is
still needed, having the option of phasing out it slowly.. (changing
the default script {} to go Lua first, and then removing the
annotations).
oh absolutely - the question more is.. to release edje 1.0 - do we remove
embryo after lua is up and fully functional (equivalent to embryo or better)
better yet, is embryo going to be maintained after that? If it's not,
then it should be removed, since sooner or later, it will fall behind
lua. so is anyone willing to maintain embryo?
-
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] RFC: embryo release in 2 weeks
oh absolutely - the question more is.. to release edje 1.0 - do we remove embryo after lua is up and fully functional (equivalent to embryo or better) I guess this depends more on how much it will take to get Lua up. The more Lua takes to be done (or at least, the more time Lua is in Edje, available to be used), the more time people have to move up and start using it, and less time of embryo secondary support will be needed. Regarding maintanence, I don't think adding new features to Embryo will be something needed, so keeping it as is shouldn't be a problem. Cheers, Caio Marcelo - 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] [ANN] QEdje 0.1
:O WOW! You guys rock my socks off! Does this mean we can get an Edje QT engine in the near future? Toma 2008/8/5 Eduardo Fleury [EMAIL PROTECTED]: Cool, any change of geting a GEdje (GTK)? I mean, to use with Gambas, for example? Hi. Our focus today is extending and optimizing QEdje (Qt) so currently there're no plans to develop something as a GEdje. Best regards, -- Eduardo M. Fleury OpenBossa labs - INdT - 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 - 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] [ANN] QEdje 0.1
2008/8/5 Toma [EMAIL PROTECTED]: :O WOW! You guys rock my socks off! Does this mean we can get an Edje QT engine in the near future? I mean an engine to make KDE themes with... I might have to take a stab at some KDE themes. Toma Toma 2008/8/5 Eduardo Fleury [EMAIL PROTECTED]: Cool, any change of geting a GEdje (GTK)? I mean, to use with Gambas, for example? Hi. Our focus today is extending and optimizing QEdje (Qt) so currently there're no plans to develop something as a GEdje. Best regards, -- Eduardo M. Fleury OpenBossa labs - INdT - 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 - 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
[E-devel] Time-based releases
Just a small follow up on this question for those who are interested in this topic. On Sat, Aug 2, 2008 at 1:52 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: No, I'm not. What I want is to stop cooking things that are already done. Sometimes I really think that Mark Shuttleworth is right WRT time-based releases, man, this would make this project so good, SO GOOD that I can't even imagine. From the technical to the social side. IMHO, I also like the idea of time-based releases. As a reference I'll put up two examples that I think are nice: 1) http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux This is about the version numbering, but IMHO is essentially a recognition from the developers (or at least Linus), that thinking about 1.0, 1.2, 2.6.26 for Linux doesn't make much sense anymore. They detached releases from features. If the new feature is ready for this one, it goes in this release. If not, cook a bit more and appear in the next. 2) https://fedoraproject.org/wiki/Releases/10/FeatureList Fedora is a Linux distribution. Here's a simplification of how it works: they organize the releases by proposing new features (whoever is going to hack propose them) for the release and keeping a status about them. The ones that are 100% when it's freeze time are in. The others not ready are moved back to proposed for the next release. I guess what Ubuntu folks do is similar. The overhead of releasing can be as simple as build some scripts to bump stuff up and generate tarballs (btw, raster already has its asparagus script that does something similar :-)...). Or am I missing something here?[*] Maybe people disagree on *what* should be called a release? Were the asparagus snapshots releases? (maybe my understanding of what is a release is too weak, I don't exclude that possibility) Or even people disagree on where should we start with these time-boxed releases? [*] btw, if you're wondering how could we do something like let's take this part out if not ready in the code, branches can help you with that, do the new features in topic branches and then integrate to main tree when they are ok. You can even keep a tree up with all those ongoing features, for people testing if you want (that's similar to what people call next tree in some projects). But I'm really not pushing git or anything here, I think this cherry picking of features is less important right now than the other questions. Cheers, Caio Marcelo - 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] Time-based releases
On Mon, 4 Aug 2008, Caio Marcelo wrote: Just a small follow up on this question for those who are interested in this topic. On Sat, Aug 2, 2008 at 1:52 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: No, I'm not. What I want is to stop cooking things that are already done. Sometimes I really think that Mark Shuttleworth is right WRT time-based releases, man, this would make this project so good, SO GOOD that I can't even imagine. From the technical to the social side. IMHO, I also like the idea of time-based releases. As a reference I'll put up two examples that I think are nice: 1) http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux This is about the version numbering, but IMHO is essentially a recognition from the developers (or at least Linus), that thinking about 1.0, 1.2, 2.6.26 for Linux doesn't make much sense anymore. They detached releases from features. If the new feature is ready for this one, it goes in this release. If not, cook a bit more and appear in the next. 2) https://fedoraproject.org/wiki/Releases/10/FeatureList Fedora is a Linux distribution. Here's a simplification of how it works: they organize the releases by proposing new features (whoever is going to hack propose them) for the release and keeping a status about them. The ones that are 100% when it's freeze time are in. The others not ready are moved back to proposed for the next release. I guess what Ubuntu folks do is similar. The overhead of releasing can be as simple as build some scripts to bump stuff up and generate tarballs (btw, raster already has its asparagus script that does something similar :-)...). Or am I missing something here?[*] Maybe people disagree on *what* should be called a release? Were the asparagus snapshots releases? (maybe my understanding of what is a release is too weak, I don't exclude that possibility) Or even people disagree on where should we start with these time-boxed releases? [*] btw, if you're wondering how could we do something like let's take this part out if not ready in the code, branches can help you with that, do the new features in topic branches and then integrate to main tree when they are ok. You can even keep a tree up with all those ongoing features, for people testing if you want (that's similar to what people call next tree in some projects). But I'm really not pushing git or anything here, I think this cherry picking of features is less important right now than the other questions. another document about release process, described by gstreamer devs: http://gstreamer.freedesktop.org/wiki/ReleasePlanning2008 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
