On Fri, Oct 28, 2011 at 9:19 PM, Mike Blumenkrantz <m...@zentific.com> wrote: > On Fri, 28 Oct 2011 11:07:45 -0200 > Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: >> I'm writing this mail so it's unified and everyone can opine without >> being in one place at one time (IRC/#edevelop). >> >> Recently I've talked to people and while I tried to express it at IRC, >> raster just got pissed and left. Later people would join and agree >> with me... so while I'm looking like a jerk I guess I'm not alone in >> there. I'll try to be as clear and short as possible. >> >> WHY RELEASE? >> 1. to clarify we know some snapshot is usable. This will get us in >> more distributions by default. > good >> 2. to remove that stupid karma over the 17 number if e. Will help >> people that do not track us closely to know we're reasonable serious. > people will probably still call it e17 even when we're on e20 >> 3. we can start to bring in new technology without delaying it even >> further (ie: elm and scripting language - js/elev8) > not really a valid reason to release, you can see it did wonders for gnome
http://www.phoronix.com/scan.php?page=article&item=gnome_survey_part1&num=1 I don't really see the link with what you are saying. >> WHY NOT RELEASE? >> 1. there are both bugs (eg: efm) > cedric has said a number of times that he'll be working on efm after he > finishes emotion soon, and I'll likely disable eeze mounting entirely for the > release since libmount is not widely deployed and I was unable to get > widespread testing until now. >> 2. missing features (xrandr, taskbar, ...) > * xrandr patches have been made and are on the list waiting for testing and > review, so I'm not really sure why this is a "missing" feature. > * New users will not be able to deal with E17 if it doesn't have a taskbar, > end > of story. Engage is in SVN now, it's usable and widely used already, it can be > merged. No you can't ! Doesn't solve the problem for non composite use case and as long as we don't make the compositer the only possible choice we can't say that engage is the answer to that problem. > * I don't care about keymap config since I'm american, but it seems important > for users to be able to type in their own language > * b&w is awful, we should switch to and iron out detourious for release Yes, that's something we should do as soon as possible. As a side question, what is the status of that theme for elementary ? Because it would make sense to also do the switch for elementary at some point. > * Improved connman support is a big sticking point for me. I strongly believe > that if the module does not improve now while it is actually a blocker for > release, it never will. To this end, it's missing 3 big features that I can > see people using: hidden network support, static ip setting, and enterprise > encryption. It's likely that this is not actually a 6 month project as you > have implied. Well, I have been using connman module since now one year and there is only one place in the world where I would have liked to have a UI to set static IP and a VPN... I am sure that's raster is in that place most of the time like some of our user base :-) So not a strong requirement from my point of view, but maybe some people at Samsung could take over that item as of course you are all using E17 ! >> EXTRA DISCUSSIONS >> * e_widgets is amazingly boring and gets in the way, people expect >> something like Elementary to help them. Or even better, for rarely >> used features like a mixer control dialog, xrandr dialog, connection >> manager configuration these things could be done with a high level >> language such as elev8. Thus lots of people would be motivated to help >> get more features in. But introducing this now would delay e17 even >> more, thus a no go. (Personal note I'm highly demotivated to hack e17 >> due this exact reason. Doing a mixer dialog in e_widget is like few >> days, in elev8 it should take me few hours -- easier to find than few >> days) > No argument here, though I think it's more an issue that e_widgets lacks > documentation. It works fine and is actually easier/faster to use than elm in > a > lot of cases once you get the hang of it. Well, I think we both are doing hugly UI, maybe we should not comment on that part. >> * we'd like to have an officially supported and widely accepted >> high level language. While I've created and maintained Python, seems >> it's hatted and going nowhere. So if it's Python, Lua or JS it >> doesn't matter, but we need one for most boring things like >> configuration dialogs and non-critical paths... (READ: I don't want it >> to be in composite manager, eborder, etc -- tho I'm open to have them >> in gadcon) > This is going to be a pain for those that don't know the scripting > language chosen, but I suppose the onslaught of progress must not be stopped. You know what, you can code in JS like you do in C. You just need to remove all that useless typing. So any one of us that know C, will be able to understand and patch JS as soon as you use it. >> AFTER RELEASE: I propose time-based releases, every 3 months we cook a >> snap and put it out. Seems to work well for everyone out there, can't >> see why it wouldn't work. IMO we can't have feature based snaps >> because we don't have enough manpower to do this promises. >> Longer release cycles are problematic as "wait my nice feature to get >> in, it's one more week! Otherwise I'll have to wait 6+ months to get >> it in!" and then this repeats forever as we see now. > reasonable >> >> >> BUT USERS WILL COMPLAIN ABOUT MISSING FEATURES: common argument for >> xrandr, keyboard languages, taskbar. Users will complain, period. >> We'll never be able to cope with minimum features, as this changes >> from person to person. Moreover, the more we wait, the more we have to >> do. Right now all other desktops implement the new systray and >> application menu protocols, really soon this will be "a bare minimum" >> for some users. There is proper PulseAudio mixer. Proper >> ConnMan/NetworkManager. Soon we'll have the user-session and seat >> management that GNOME is doing with systemd... This list is lways >> growing. But we're short on human resources. Having a release and >> getting Elev8 into E would help bringing more people to help. > If we cared about user opinions so much, we probably wouldn't be working on > E17 > at all anymore. As for new minimum features, let's be realistic: nobody is > ever > going to implement that stuff before E17 release even if it's a requirement. > We > got pulseaudio support (the newest "desktop" feature) because I had fun > abusing > the native protocol, and that's not even cutting edge. That's the point of increasing the size of our community, so that people that think it's funny to implement that kind of stuff do it. >> MY PROPOSAL: just fix the remaining efm bugs and other outstanding >> crashes and do a release as is. Remove the e17 karma and get back to >> normal life, get e18, e19... and things go into them as fast as we >> can. > End result: VETOED. > The items in http://trac.enlightenment.org/e/wiki/Release were discussed and > agreed upon for a reason. Your personal lack of desire to complete them should > not influence the release date, and others are actively working on them. As stated in my previous mail, I am for jumping on releasing an alpha as soon as we have our main bug gone and try to target to do that at the same time as 1.1. It will just be a benefit, driving developer attention and maybe gather some help to finish the last round of work. Because face it, we have very few people motivated to fix the last item right now. But we have people that would have been helping if a few technological limitation where removed. So we need to shorten the painful path as much as we can. -- Cedric BAIL ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
