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 S. ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
