On Tue, 4 Dec 2012 12:33:15 +1000 David Seikel <onef...@gmail.com> wrote:
> On Mon, 3 Dec 2012 23:07:25 -0200 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: > > > > > > > On 03/12/2012, at 21:50, David Seikel <onef...@gmail.com> wrote: > > > > > On Mon, 3 Dec 2012 20:23:48 +0900 Carsten Haitzler (The Rasterman) > > > <ras...@rasterman.com> wrote: > > > > > >> On Mon, 3 Dec 2012 20:17:49 +1000 David Seikel > > >> <onef...@gmail.com> said: > > >> > > >>> On Mon, 3 Dec 2012 10:03:24 +0100 Vincent Torri > > >>> <vincent.to...@gmail.com> wrote: > > >>> > > >>>> On Mon, Dec 3, 2012 at 9:55 AM, David Seikel > > >>>> <onef...@gmail.com> wrote: > > >>>>> On Sun, 2 Dec 2012 23:45:46 +0100 Vincent Torri > > >>>>> <vincent.to...@gmail.com> wrote: > > >>>>> > > >>>>>> hey > > >>>>>> > > >>>>>> i've aded ecore in efl/ I'm pretty sure that there are plenty > > >>>>>> if bugs. Please report them here > > >>>>>> > > >>>>>> There are also plenty of improvements to do too, i'm aware of > > >>>>>> that. > > >>>>> > > >>>>> I noticed you made ecore_con compile mandatory. > > >>>> > > >>>> indeed. Is it a problem for you ? > > >>> > > >>> Yep, as I have mentioned before, this embedded project I've been > > >>> working on has legal requirements that must be met, and an audit > > >>> lab that it has to go through to make sure it meets those legal > > >>> requirements. One of those legal requirements is to not have > > >>> anything on the device that is not actually needed for the > > >>> device to perform it's specific legal function. On top of > > >>> that, the less there is on the device, the less time it will > > >>> take the audit lab to audit it, the cheaper the audit will be. > > >>> The device does not need networking, so leaving out ecore_con > > >>> would be good. > > >> > > >> ecore-con is not just for "networking". it's for ipc. ecore-evas > > >> requires it because ecore-evas supports remote ipc canvases from > > >> other processes (ecore-evas-extn). in the bid to simplify our > > >> ifdef hell we have and ensure people have an always usable setup > > >> - ecore-con is now on by default. > > > > > > I don't need IPC or remote canvases either. > > > > > > And yes, it's still a problem for me. Now I have to explain to > > > the audit lab that while there is now the potential to connect up > > > to the device over a network and use this fancy ecore_con thing > > > to add new functionality and change what's on the screen, thus > > > potentially bypassing the legal requirements for our own > > > nefarious purposes, I promise that we don't do that. Cross my > > > heart and hope to die. > > > > > >>> Raster said that --disable-foo options will get replaced by > > >>> "just delete the libfoo.* files". I'm hoping that is stuck to, > > >>> at least for the stuff *I* don't need. B-) > > >> > > >> not in all cases. see above. :) > > > > > > EFL 1.7.2 let my remove fontconfig and it's dependencies, but made > > > me add pthreads and ecore_con. At least there was still an > > > overall decrease in the resulting flash image size. > > > > > > EFL giveth, EFL taketh away. > > > > Do you see it makes no sense to add a burden for everybody because > > one single user with strange requirements? > > While that is true, I'm allowed to whinge about it and let my needs be > known in case it's not really that much of a burden. How much of a > burden it is I don't know, I'm not familiar with ecore_con and it's > internal usage. Though the fact that it worked the way I wanted it to > in the past suggest it's not that much of a burden. > > Sure my legal requirements are peculiar to my class of device, so > that's not something that needs to be applied to EFL. On the other > hand, not needing network and IPC, while needing things to be as small > as possible, I would expect to be a common requirement in embedded > work. It's also common for embedded devices to be subject to legal > requirements, though I suspect not as many as mine is, governments > tend to be paranoid about these things. lol > > I state my needs, if that's too hard, even though my needs where met > in previous versions, then I have to live with that. The fact that > these sorts of changes make my life much harder I will mention each > time. I would not mind so much these changes making my life harder if > it was not for the reasons I pointed out in that other merged ecore > review thread. It basically boils down to "my project was designed > around the feature of EFL that let me cut out lots of stuff". That > feature is going away now that it's too late to change the design, > this creates more work for me on a fixed price contract. I don't > like being forced to do free work for paying clients. That this > feature is going away was not apparent when I quoted for the job. > > It's a fact, there was a bug on the older EFL tarballs (fixed in 1.7) > that was ending up to be too hard to work around, plus updating to EFL > 1.7 meant I could remove two more no longer mandatory dependencies. > The fact that an optional part of EFL is now mandatory is a problem > in this case, so I stated my need. Overall it was a benefit to > update to 1.7.2, I just wish it was a bit better. Otherwise I would > have stayed with the pre 1.7 releases. I intend to stick with 1.7.2 > for this project, unless there's further bugs that an update might > help. There's no more recent release at the moment, so that's > theoretical now anyway. > > I actually have a future project planned for this same client, but I > have already quoted on that job. The basic deal is that this first > one is written in a more generic style, and the second one will be > based on it. Another good reason for going with EFL, I think the > second project could be done mostly by just changing the EDC. B-) > > If the merged EFL tree is actually more suited to my clients > requirements than 1.7.2 when the merged version is released, and that > release is before I've done a lot of work on the second project, then > I might consider using it for the second project, and providing an > update for the old project. In this instance "more suitable" means > A) it results in less things for the audit lab to worry about. B) it > does not need me to do a lot of unpaid for work to update this > project. C) less bugs that are important to this project. D) > anything added that might make my job easier, especially if that > offsets the extra work needed too update. So I'm speaking up about > SVN merged EFL tree in varios places with regards to this project, > just in case it ends up being useful for this project. I already > mentioned, everything else I'm doing with EFL outside of this clients > work, I'm quite happy with merged EFL tree and how it is progressing. > > > I really doubt that due the nature of your software you can be > > linked to SVN head anyways, as we commit shitloads of code that > > would need to be re-audited on every update. > > No I don't use SVN head, I use released tarballs for this one project. > I use released tarballs for all external dependencies and things like > the Linux kernel and libc. Telling the audit lab "It's just standard > releases of Linux, uCLibc, busybox, etc as used in many other systems > all over the world" will help them to do their job. Using that same > argument for released EFL tarballs I might be able to fudge over by > saying "Samsung and others use it.". B-) > > But I get to have my say in how SVN head is developed prior to it > being released as a tarball. Coz it's too late to have input into > things once it's released. > > The audit lab will look harder at my EFL usage than it will at my > Linux usage, simply coz Linux is way more wide spread and understood > than EFL. So yes, having less EFL for them to worry about is very > important to me, and to my client. Saves him money on the audit. > > > If that is not s problem, just justify the new hard dependencies as > > those other changes. > > The only justification is "upstream decided it's too hard for them to > keep it optional like they used to". I have no other reason why it's > there. That might be a hard sell, considering that it can be used to > arbitrarily change what's on the screen from a network, and the legal > requirements for what's on the screen are even tighter than the ones > for what's on the disk. > > There is in fact legislation concerning network attached variations of > these devices. The one I'm working on is not such a beast. The > legislation requires that if it is such a beast, that you use the > government written network API. I'm so fucking glad I don't have to > do that. lol Actually, I just remembered that this argument is about ecore_con in SVN, not in 1.7.2 head. Ecore_con is not mandatory in 1.7.2, except for the fact that the autofoo crashes when you try to disable it. That's what I complained about initially, and Vincent agrees that should be fixed. If ecore_con IS mandatory in 1.7.2, then the option to disable it should be removed. Either way, something needs to be fixed. Perhaps a 1.7.3 will be released and I'll test that and see how that affects this issue. If a theoretical 1.7.3 means I can disable ecore_con, and there's no other issues that mean I have to update again later for this project, then that will make me happy. Ecore_con being mandatory in SVN head's merged tree I guess I'll not worry about if 1.7.2 works fine for the embedded contracts I have that are subject to these strict legal requirements. I'm just getting my bitching in early while it's still under development and easier to reverse that decision. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
