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
