On Wed, Nov 21, 2012 at 5:48 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
> On Wednesday, November 21, 2012, Thomas Sachau wrote: > >> Gustavo Sverzut Barbieri schrieb: >>> On Wednesday, November 21, 2012, Carsten Haitzler wrote: >>> >>>> On Wed, 21 Nov 2012 13:54:14 +0000 Michael Blumenkrantz >>>> <michael.blumenkra...@gmail.com <javascript:;> <javascript:;>> said: >>>> >>>>> On Wed, Nov 21, 2012 at 1:47 PM, Carsten Haitzler < >> ras...@rasterman.com <javascript:;><javascript:;> >>>>> wrote: >>>>> >>>>>> On Wed, 21 Nov 2012 13:18:41 +0000 Michael Blumenkrantz >>>>>> <michael.blumenkra...@gmail.com <javascript:;> <javascript:;>> said: >>>>>> >>>>>>> ah, how quickly bets are made against me the instant I leave the >>>> country. >>>>>>> my league of admirers is always so reliable! >>>>>>> >>>>>>> distcheck is always run before a release. always. >>>>>> then how did it pass when the edje_cc in the 1.7 branch literally did >>>>>> crash in >>>>>> this scenario - it wasnt random. it literally was ALWAYS a strcmp >>>> against >>>>>> NULL... >>>>>> >>>>>>> I said previously that I run the stable branch at work; I'm not at >>>> work. >>>>>> aaaah so you didn't distcheck this one against stable branch? >>>>>> >>>>> I'm on vacation, bedridden most of the time with the German Plague and >> a >>>>> fever so high that the top of it can't be seen from the peak of Mt. >>>>> Everest. Despite this, I managed to drag myself to my computer to try >> and >>>>> do a release. >>>>> >>>>> I would appreciate greatly if people could stop being less negative and >>>>> critical, and instead focus more on being both productive and >>>> constructive. >>>> >>>> fair enough - i just never expected this should even get through if you >> are >>>> building/testing against 1.7 - since you are not right now that dos >> create >>>> some >>>> issues and changes expectations that you are testing against that. >>> >>> How about you, Raster? Are you able to test with 1.7.x? You've mentioned >>> this edje_cc bug and the Evas leaks. Anything else that is know but >> pending >>> to be debugged in EFL (leaks, crashes) or we can do a 1.7.2? >> If doing a full release cycle for all released libs is too much work, >> what about just a minor release for edje (like version 1.7.1.1), so that >> users can again use release tarballs to build alpha4 of e17? > Seems reasonable. But I guess there are other stuff in other libs to be > out. They just wanted to get it closer to e17 being out. > > I'd say we need the libs should be out before e17, then we can make sure it > works. > > Then the only situation to avoid releasing EFL is if there is something > pending fix (leaks, crashes) that must get done before such release. > It shouldn't happen when blocker issues were fixed. > There is definitely no point in releasing a new tarball that can't be > used with 1.7.x branch. > It's blocker, new e17 tarball won't build. > > In this case a version 1.7.2 should be released. > > Before releasing e17, most probably more fixes will be done, and a > version 1.7.3 should be released. > But if another blocker issue is found, another release would be required > before. > > Sure, it's impossible to Mike handle all this stuff alone. Luis > commented he and Mike were talking about creating a release team or > something like that to handle this situation. > Most probably they will send something to the list about it soon. > > Regards. +1 There should also be a efl 1.7.x beta out a week before the final e17 release so we get atleast 2 e17 beta's built against it, Neither should change to much unless something goes horribly wrong failure to do this could quite likely mean emergency bugfix releases within a week after the actual release. I prefer the idea of a edje 1.7.1.1 to patching it manually (Atleast we all still have the same codebase) however Bruno's suggestion is definitely my preferred one. In my opinion If everyone is so under the pump and busy they can't do a 1.7.x release this week the e17 release should be pushed back 1 week (or till the new year if its more practical) due to major issues found during alpha. In my opinion having a release date and slipping it by 1 week to make the software more reliable is better then meeting the release date with buggy software, I also believe its better to have a release date to aim for then possibly let it slip a little then to just release when its ready, because you will always have some idea or something that you think should be re written to stop you from releasing. In my opinion release dates particularly when there is no big contract waiting on it should always be atleast a little flexible. Slipping by only a week or 2 in a 12 year cycle is really alot better then most other projects i have ever seen. Simon >> -- >> >> Thomas Sachau >> Gentoo Linux Developer >> >> > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN:barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
