Hello. On Thu, 2012-06-14 at 19:37, Vincent Torri wrote: > > On Thu, Jun 14, 2012 at 12:56 PM, Stefan Schmidt <s.schm...@samsung.com> > wrote: > > Hello. > > > > On 06/14/2012 11:50 AM, Carsten Haitzler (The Rasterman) wrote: > >> On Wed, 13 Jun 2012 14:30:58 +0100 Stefan Schmidt<s.schm...@samsung.com> > >> said: > >> > >>> Hello. > >>> > >>> We just had a short discussion on IRC about keeping or removing the HAL > >>> backend used in E and EFM for the release. Main points seem to be: > >>> > >>> Arguments for removing: > >>> - Mike as our main device backend guy does neither care nor use HAL. He > >>> supports udisk and eeze mounting though. > >>> - Keeping the code in for the release means we have to maintain it and > >>> fix bugs. > >>> - HAL upstream seems dead. > >>> > >>> Arguments for keeping: > >>> - The BSD users still use it (There seem to be a udisk port for *BSD > >>> http://ftp1.fr.freebsd.org/mirrors/rsync.frugalware.org/frugalware-stable/source/xapps/udisks/, > >>> any of our BSD users is using that) > >>> > >>> I there anything missing? I would like to hear back from people using a > >>> recent (as in svn checkout) E with HAL and their reason. > >> > >> maintaining edbus hal means doing nothing - its protocol never changes. > >> which > >> is good. > > > > Well, if BSD or the former solaris crew keeps their own fork that migth > > still change. Anyway, I agree the edbus HAL part is not a real issue. > > > >> as for hal in e using edbu's shal api - yes, maintenance is needed, > >> BUt we can remove it any time in future when no more hal installations > >> exist, > >> but bsd as you mention does so i think we are best off keeping it as hal > >> has > >> worked fine in the past and since hal is not a moving target, neither is > >> support :) > > > > Well I was thinking along the lines of changes we do to efm and other > > backends which no longer will work with the HAL backend as nobody tests > > that. Add some point people will complain and it might be really hard > > for us to fix it as we don't have HAL anymore and thus it would be hard > > to reproduce. > > > > All hypothetical anyway. If you guys want to keep it its fine with me. > > Just wanting to point out that we are "stuck" with supporting it after > > the e17 release. We are stuck with the HAL part in edbus anyway as it is > > already released. > > I've discussed a bit with the devs of Illumos (the fork of the kernel > of opensolaris) about HAL replacement. Currently, there is no plan, > though they would like to get rid of it. On the other hand, they would > like to have e17 with HAL support. > > There is a port of udisks for FreeBSD, at which they could have look > and could fork it, unfortunately, the code if GPL, which is > problematic for them. > > So, if possible, even if the HAL code is not maintained, if you can > keep it, that would be nice. I still plan to keep e17 working on > Openindiana (the fork of opensolaris, based on illumos)
Thanks for getting in touch with all this people. I would say it is settled then. We keep HAL support in E17 for the release. Lets hope it does not break that often. :) regards Stefan Schmidt ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
