2011/11/11 Vincent Torri <vto...@univ-evry.fr>: > > > On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote: > >> 2011/11/11 Vincent Torri <vto...@univ-evry.fr>: >>> >>> >>> On Fri, 11 Nov 2011, Gustavo Sverzut Barbieri wrote: >>> >>>> On Fri, Nov 11, 2011 at 3:23 PM, Vincent Torri <vto...@univ-evry.fr> >>>> wrote: >>>>> >>>>> On Fri, 11 Nov 2011, Iván Briano (Sachiel) wrote: >>>>>> >>>>>> 2011/11/11 Vincent Torri <vto...@univ-evry.fr>: >>>>>>>> >>>>>>>> The problem with that is guaranteeing that the entire thing builds. >>>>>>> >>>>>>> make distcheck... >>>>>>> >>>>>> >>>>>> And if it doesn't build you have the script keep trying? There's the >>>>>> OBS >>>>>> for that, though I don't know if it provides the tarballs too. >>>>> >>>>> make distcheck || exit 1 >>>>> >>>>> that way, the script exits on error. So really, there is no problem at >>>>> all. You can also retrieve the error code, and let the script >>>>> displaying >>>>> message, sending a mail, etc.. and exiting cleanly >>>> >>>> Let's remember that "if it build, ship it" is not a good one. Many >>>> things may fail even if they compile, like some incorrect string that >>>> was changed with a typo. >>> >>> same problem when we release, so... Release is basically : we update >>> version, some file, make distcheck, we copy the tarball somewhere. >>> >> >> Nah, you usually test releases to make sure they actually work, instead >> of just firing make and uploading the package if it didn't fail. > > we can say : hey, here are dayly snapshot, these are compiling but must not > work correctly". And you gave the list of dayly snapshot > > note that i wanted to do that for the freeze period. I don't see why you're > relunctant to an automated process that requires 0s of work, except the > basic shell script. > > But when that thread will end, the freeze period will be over... >
I'm not reluctant to doing that, I'm keeping this within the context of the original request. The freeze for the release ends next week, so the release will happen around that time. I don't think setting up such a system now makes sense within that context, but if it gets done for the long term it's fine. > Vincent > >> >>> Vincent >>> >>>> I agree with Sachiel and think they want some guaranteed-to-work (at >>>> least on Linux) tarballs, that they can use and assume all problems >>>> found are OpenBSD specific and not bug on the generic parts. >>> >>> >>> ------------------------------------------------------------------------------ >>> RSA(R) Conference 2012 >>> Save $700 by Nov 18 >>> Register now >>> http://p.sf.net/sfu/rsa-sfdev2dev1 >>> _______________________________________________ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> RSA(R) Conference 2012 >> Save $700 by Nov 18 >> Register now >> http://p.sf.net/sfu/rsa-sfdev2dev1 >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
