On Sat, 10 Nov 2007 15:46:44 +0100 Michel BRIAND <[EMAIL PROTECTED]> babbled:
> Hi, > > Fist, your involvement and wisdom as team leader is respected and > appreciated ! > > Ulisses said: > >Formalising can be a good thing, I think. We could even try to change > >our workflow and start using git. What do you think? > > > > Yes, git is a good trade, everyone noticed that CVS is so slow, and > that's prevented devs from tagging releases in the past. it is? how much more local disk space will this take up? keeping lots of revision history locally is going to eat up local space. it's going to kill rsyncing of homedirs from box to box... i am wary of git. CVS is lean client-side. i see nothing slow about it. what's slow? note i use CVs from japan/australia/asia and have no problems - it sits in the usa. so those in the usa will have even better service to it, and i can't see any problems with it being slow. ? > Since there are many "packages" (libs & apps) to manage in parallel, > and provided that there is often large impact after a lib change, it's > of a good value to think about defining good procedures to > commit, update, build and test. > > So the good script e17_build should be included in the main source tree, > and improved so that everything is built & tested against either (quick) > "latest" source tree, either (better) "tagged" releases. > > It could sounds a bit hard but since the project has became (to our > satisfaction) larger, there are more devs, and consequently there are > more code clashes ;). In that way, everyone should think about "how > the rest of us would handle my changes?". the problem here is that you are trying to unify e as 1 big thing. that just makes management and releases worse. you want to SPLIT it up. you want to have separate development tracks so if 1 side-branch of work breaks - its just that branch affected. > Git does not provide it all, it's a tools that enable us to do it;). > Good practices, and good scripts, could make it real and help. i'm wary of git. it is a completely different model to which we have used for many many many years. changing scm will be a big change for us - everyone. it took x.org months to move to git. git also encourages people to hoard their own little repositories and "branches" instead of keeping it all together in 1 place to fetch/inspect/modify. we can keep our stuff in 1 place and not have to link that to having to build everything that happens to be in that 1 place. > Raster said: > >> 1. Identify people who WANT to be leaders and shape the direction of > >> E - and are willing to spent the effort. Some of you do it as a > >> hobby and love just that, some do it for a job, others are in > >> half-way houses. > > Some people are using EFL in their project. They know it's alpha > software. But they would benefit of a more paced & predictable cycle of > updates. yes. and to get there we need to finish off what we have and not add new ideas/things to it, but get what we have done and out the door. > More important, those people that make use of EFL to create applications > have a lot of problems that may help EFL development. A good interface > with those people seems to me a good value for the overall process. > > It's also a good testing ground if companies would support us, or would > invest in using EFL in their projects. > > Raster said: > >> But the primary thing of importance is getting E17 out the door. > > Oh yes ! > :^) > > Raster said: > >> I hope that everyone can be just as excited. I know I am. I smell a > >> new age of... Enlightenment. :) > > Yes ! I think it's a great opportunity. > > Vincent said: > > I was just wondering if it was the right time to start a new theme, > > which is a big big work. > > To my understanding it should not be a big big work. I don't know > precisely the difficulties, I only read the documentation of edje... > Improving this tasks by simplifying and standardizing theme creation > would be great ! > > One idea for the desktop shell ;o) : > > some colleagues and I, in the field of UNIX development & support, are > always searching for simple tools, portable, to create graphical > feedback in shell scripts... > > We went looking into tck/tk, perl/tk, xmessage, .... and a lot of > "dialog" tools programmable from the command line, on Linux, Solaris, > HP-UX, ... And as you probably know it's a mess ;o)... > > Beside this we always wondered why the "Open file" dialogs in all > graphical toolkits (gtk, qt, kde, ...) were so different, so far from > the user, .... > > If EFL file dialogs were usable in shell scripts it would be great. > Device handling facility (open usb disk of my E17 desktop, sending a > picture back to my desktop through bluetooth if I had E17 on my > mobile, ...) would be great also ;). > > So designing a good set of very basic "dialogs" with the very focus of > ergonomics in mind should be a central thing in e+evfs+desktop future. > Keeping the efficiency of EFL, portable as it is, fast, beautiful, > simple .... that's extra work, not on the todo list. :( > Looking at major end user interface, one can see that Compiz-Fusion, > in the Linux world, is becoming the favored desktop for a lot of > people, and, in the Windows world, you should agree that > Windows Vista has became nice to look at ;).... not sure about that - but lets see. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
