On Mon, Oct 31, 2011 at 2:59 PM, Vincent Torri <vto...@univ-evry.fr> wrote: > On Mon, 31 Oct 2011, Lucas De Marchi wrote: >> Hi, I'm not responding to the entire thread because it's pointless... >> only one thing below. >> >> On Sun, Oct 30, 2011 at 10:26 PM, Carsten Haitzler <ras...@rasterman.com> >> wrote: >>> On Sun, 30 Oct 2011 14:41:44 -0200 Gustavo Sverzut Barbieri >>> <barbi...@profusion.mobi> said: >>> >>>> On Sunday, October 30, 2011, Carsten Haitzler <ras...@rasterman.com> wrote: >>>>> On Sun, 30 Oct 2011 11:56:07 -0200 Gustavo Sverzut Barbieri >>>>> <barbi...@profusion.mobi> said: >>>>> >>>>>> Sorry David, but what we are trying to show is that we have a >>>> psychological >>>>>> problem. Going code to solve the technical problem is not solving the >>>> worst >>>>>> one, the psychological. >>>>>> >>>>>> At IRC we also talked about the shameful behavior post 1.0 EFL. We did a >>>>>> release since the technical details were over, yet we failed to overcome >>>>>> the psychological problem and no releases after it. Even tho major bugs >>>>>> were fixed (stable bugfix) and great amount of features were done (new >>>>>> release). >>>>> >>>>> you must. have a blindfold on. you are blinkered. >>>>> >>>>> http://www.enlightenment.org/p.php?p=news >>>>> >>>>> jan 29 - efl 1.0 >>>>> may 25 - efl 1.0.1 >>>>> aug 5 - eeze 1.0.2 >>>>> >>>>> and right now we are in merge window for 1.1 - did you not read my email >>>> to >>>>> e-devel about it? apparently not. >>>> >>>> I did, yet it should have been done months ago, not now. >>> >>> at this point you lost all credibility. you said "no releases". i quoted >>> our own >>> release announcements and you STILL stick to your line. WHY should 1.1 have >>> been >>> done months ago? what amazing world changing thing would it have >>> accomplished? >>> what DID YOU DO TO TRY MAKE IT HAPPEN? >>> >>> let me look at time gap between releases of qt 4.6 and 4.7 ... GOSH!! >>> 12/2009 >>> vs 9/2010. 9 months! oh look... we have almost exactly the same gap! sure >>> they >>> did 4.6.1/2/3/4 in between, and we only did 1.0.1. but now... we're >>> obviously >>> WRONG and must release much earlier! >>> >>> you have not given 1 sensible piece of information as to why we all of a >>> SUDDEN >>> must do a release in the next "2 months". what world changing event will >>> happen >>> that if we miss it will kill us forever so that we must drop everything we >>> are >>> doing? why should we suddenly drop the plans that exist? how are YOU going >>> to >>> help (if you have already given up and are so demotivated you won't help >>> anyway)? why should those left doing work dance to the tune of those >>> sitting in >>> their armchairs? >> >> What you seem to be missing is not that we want the thing to be >> suddenly released. We should be discussing whether releasing in a >> timely fashion would be better for the project than the current >> not-written-anywhere plan of releasing when a a TODO list is done. >> What several projects are using this days is to set a date and a TODO >> list; if the features are not ready when the stabilization period >> arrives, the features are dropped and postponed to another release. >> >> Another scheme that some projects use is release-veeeery-often... this >> is what is used in systemd/udev/bluez/connman for example. >> >> Both the approaches above have the benefit that Distros can package >> recent versions rather than a 1 year old library > > I think that it is a good point. Let's see what we will do after the 1.1 > release. Maybe someone who will be the release manager.
I agree with you Vincent, I have already stepped on doing the minor release. I thing I can continue to do so for 1.1.x branch. But the futur of this branch depend onn wether we switch on a time based release or not. > If I'm not mistaken, several projects use one different maitainer for each > release, so that not only one person is in charge of this big task. Yes, and I thing it's a good idea. I don't think that it's needed that every time raster need to do it. We should just fix targeted month and ask if someone want to step in for that release. At least that wouldn't put that much work always on the same person. >> that sw are not using >> anymore. Distros will only package lib/sw that is released. If we take >> too long to release, software written using EFL will very often depend >> on svn versions. Take WebKit-EFL for example... every time we receive >> complaints of WebKit-EFL not compiling we have to say "humn... you >> have to use EFL from svn". >> >> Regarding e 0.17 I'm really demotivated to do anything. It's taking >> long to be release and next version will be a major rewrite to use elm >> and/or script languages... why bother writing anything that will be >> dropped on next release? > > If I'm not mistaken, e18 will not be a complete rewrite of e17, but an > enhancement of e17. So I think that knowing e17 will help in coding in > e18. As far as we discussed what will be in e18, it's mostly change in the infrastructure, no big rewrite at all. So any work that is done on the TODO now will stay for some times in svn in my opinion. -- Cedric BAIL ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
