On Fri, 11 Nov 2011 14:19:12 +0100 Jonathan Armani <d...@asystant.net> said:
> Hi, > > On Fri, Nov 11, 2011 at 8:00 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Thu, 10 Nov 2011 18:18:29 +0100 (CET) Vincent Torri <vto...@univ-evry.fr> > > said: > > > >> > >> Hey > >> > >> I'm talking a lot with an openBSD dev, and currently it's very hard for > >> them to follow the changes in the trunk. What they would like to have is > >> snapshots to provide easily patches for the EFL. > > > > how is that hard? svn checkout or update instead of wget. u also need to run > > autogen.sh. > > > >> Would it be possible to have, during the freeze period, some daily > >> snashots ? It would be nice to fix the openBSD port for the release. > > > > open to patches, but none have been submitted. > > Are you kidding ? I though you were reading the svn log. I take a lot > of my time pushing / polishing these diff (special thanks to vtorrin, > bluebugs and billiob). > So you come from nowhere and make all this work looking bad, here and > on irc, that's amazing. you don't have commit access. so you can't be committing. i see zero emails from you on e-devel with patches... the first i saw of any patches was when vtorri pointed me to them. no - i'm not reading every commit mail. this is the first email from you on this list... you've never poked up with a question that i have ever seen related to your patches, which definitely went off and did the wrong thing. and yes - many of the patches were bad. what made you think changing evas_object_color_get() to use unsigned char *'s instead of int *'s was good? https://github.com/jarmani/mystuff/blob/master/x11/e17/evas/patches/patch-src_lib_canvas_evas_object_main_c it looks bad. it *IS* bad. that's an instant api and abi break just on openbsd. i'm not allowed to say that that is bad? many of the patches to evas, edje, and more were to adjust for this api/abi break to a stable abi. there isn't anything there to fix in changing that. you just make sure that applications built correctly will have bugs/crashes/errors on openbsd by doing this. also patching more libs to not used chained_mempool because you disabled it in eina's build wasn't a great move. you should have kept it enabled and if you thought that it's pool allocator was just a repeat of bsd's libc one - just patched chained_mempool to straight through use bsd malloc/free. it would have been a simpler, less invasive patch. in addition you're patching configure scripts and Makefiles as opposed to their source (configure.ac, Makefile.am) which may just patch over your immediate problem, but won't work in the long run as every time you run autogen.sh you overwrite your changes. a change in autoconf or m4 macro sources can instantly nullify the patch. it also will break for releases too per new release. it's much better to identify the source in the Makefile.am or configure.ac and find out why its generating something that doesn't work for you and fix it at the source (well that or in autoconf or automake directly itself and maybe its macros and templates). i saw these and yes - i said it was bad and i wish you didn't do things like break api's on openbsd without talking to use first and at least asking why something is how it is. > if they require tarballs to > > test and can't just run svn instead to fetch the source... i don't have the > > time each day to make tarballs when they can just as easily fetch from svn. > > it's the same work on their part. making tarballs is MORE work on our part. > > You missed the point, we want to be sure that the final archive will be ok. > I'm not asking for snapshot on a daily basis, only some rc before the > final archive. > (Wait no project did alpha & rc, right ?) the final archive will be what's in svn - as per make dist. make distcheck ensures that you ship what you are meant to. the rest is ensuring the source in svn has bugs fixes and documentation is up to date. there isn't an rc or alpha because there's still things to be done before that and they are being done. i was going through news files today as well as some bugfixes. > >> Note that i discuss also with a Mageia e17 maintainer, and he told me that > >> such snapshots will help him too. > > > > a snapshot has no more quality than an svn checkout, so other than a mental > > block thinking svn == totally unstable/unusable and an unwillingness to use > > it because of a mental block, i don't see the point. > > yeah a mental block, I think you don't want to know how many time I > have to reroll a dist to get all working and how frustating it is. and equally having to make dist tarballs every day is frustrating, eats up time and is no better quality than an svn checkout unless it sucks up even MORE time. vincent suggested daily snapshot tarballs. i say that that is the same as svn checkout so where is the value in doing the extra work? i get the message "OMG! he dissed my patches and isn't giving me what i ask for! i'm going to make an issue about it!". your patches were bad. they committed a major sin - they CHANGED the API of evas. that *IS* bad. now if you are done trying to make me look bad because i complained about the patches and that i hadn't seen or heard of them until today, then maybe you can actually discuss why you did some of them (the chained_mempool i already heard and offered a simpler solution if you want to do that, though it's just buys work really - even the simpler solution). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
