A possible solution. S.
Stefan Schmidt <ste...@datenfreihafen.org>: >Hello. > >On Tue, 2013-12-10 at 09:10, Sebastian Dransfeld wrote: >> >> On 12/10/2013 08:19 AM, Stefan Schmidt wrote: >> > Hello. >> > >> > On Tue, 2013-12-10 at 14:32, Carsten Haitzler wrote: >> >> On Mon, 9 Dec 2013 20:23:39 -0500 Michael Blumenkrantz >> >> <michael.blumenkra...@gmail.com> said: >> >> >> >>> On Tue, 10 Dec 2013 09:34:57 +0900 >> >>> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: >> >>> >> >>>> On Mon, 9 Dec 2013 19:02:50 -0500 Michael Blumenkrantz >> >>>> <michael.blumenkra...@gmail.com> said: >> >>>> >> >>>>> On Tue, 10 Dec 2013 08:51:50 +0900 >> >>>>> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: >> >>>>> >> >>>>>> On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt >> >>>>>> <ste...@datenfreihafen.org> said: >> >>>>>> >> >>>>>>> Hello. >> >>>>>>> >> >>>>>>> On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: >> >>>>>>>> Hello. >> >>>>>>>> >> >>>>>>>> On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: >> >>>>>>>>> I'm not sure this is the case - just like Simon alpha4 builds fine >> >>>>>>>>> here. >> >>>>>>>> Really strange. I reviewd the commits that gone into rc1 and efl >> >>>>>>>> 1.8.2 but I can't see anything that broke this. Also its building >> >>>>>>>> fine for me and on jenkins. >> >>>>>>>> >> >>>>>>>>> At any rate I guess I'll try just disabling physics then. >> >>>>>>>> Please do. The physics module was not really maintained and Mike >> >>>>>>>> just removed it so it will be gone in the next rc and the final >> >>>>>>>> release anyway. >> >>>>>>>> >> >>>>>>>> Having it disabled manually for the rc1 should be ok for the people >> >>>>>>>> encountering this problem. Does that sound good for you guys? >> >>>>>>> To avoid any more confusion on this Mike and I decided that I will >> >>>>>>> prepare a new rc1 tarball with the removal commit and upload it. Will >> >>>>>>> send a mail once its up. >> >>>>>> how about.. rc2? :) >> >>>>> I don't want to drag this process out unnecessarily. >> >>>> there are still bugs being filed on phab... and i was more making the >> >>>> point >> >>>> that re-spinning a tarball with the same name/version is not a good >> >>>> thing. >> >>>> "which rc1 do you have?" "i don't know. rc1!". :) if there is a >> >>>> re-spin.. at >> >>>> least call it rc2... :) i could have done a "re spin" for 1.8.1 (another >> >>>> 1.8.0) as no code changed - it was a m4 macro doing the totally >> >>>> unexpected. >> >>>> but i had to do 1.8.1 :( >> >>>> >> >>> there was no "re spin" as you call it. the tarballs sent to the list were >> >>> PREVIEW tarballs, and it was explicitly stated that they may or may not >> >>> have >> >>> been the final release tarballs for those versions. you absolutely could >> >>> not >> >>> have done the same thing, as you did not send your prepared tarballs to >> >>> any >> >>> lists prior to doing the release. >> >> so i downloaded rc1. is mine fixed? :) you didn't answer that. how do i >> >> know if >> >> its the respin or not before i download it? >> >> >> >> even for rc's if there is a re-generate at sall it should get a new name >> >> for >> >> the archive. rc2, rc3, rc4 etc. imho >> > It is clear what you mean. The problem is that we want to publish >> > tarballs _before_ we make them final. Even for rc or alphas. >> > >> > I agree that the way I updated the tarball was a bit problematic. I >> > see two ways out of this. a) a staging area where we upload tarballs >> > for testing and only move them over to the final destination once we >> > call them final or b) do as you suggest and increment the number >> > every time the tarball changes but keep it on the correct location. >> > >> > The later could also cause confusion when you have to bump the number >> > in to short time to allow more testing. Like you fixed one problem, >> > re-upload with higher number and do it again shortly afterwards for >> > another bug. You wanted to release 1.8.1 but end up with 1.8.3 within >> > a day before the actual announcement. We could do rc's for stable >> > updates as well. >> > >> > None of the solutions is really convenient. Need to ponder this. >> > >> >> checksum file > >You mean we miss them in general from our releases or that it could be >used as a solution to this? > >regards >Stefan Schmidt > >------------------------------------------------------------------------------ >Rapidly troubleshoot problems before they affect your business. Most IT >organizations don't have a clear picture of how application performance >affects their revenue. With AppDynamics, you get 100% visibility into your >Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >_______________________________________________ >enlightenment-devel mailing list >enlightenment-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
