Thankfully, Xavi Artigas fixed. Even though unstable but it's compilable on devel branch now.
Actually, efl has been bad at compatibility so far. After 1 year leaving, Enventor has totally collapsed which was stable enough. It's not about interface nor compilation but behaviors. UIs is too fragile now, entry and focus in Enventor showed me the worst compatibility among that. It's too shame. Since efl is a very huge system. many committers are not easy to understand whole bunch of code and history. I agree with zmike, bu5hm4n and other people about review process. We need more strict patch review. But I'd rather say, it doesn't mean just review but the real review by actual maintainers. Submitting patches without actual maintainer's review shoudln't be acceptable even if they are committer. If a non-maintainer reviews code, verifies it, situation won't be different. In my experience, unstable efl has not come from the misunderstanding of programming language, eye-catching compatibility breakage, crash and simple logic change inside the function. Sometimes we do mistake but it's not too critical. We can easily find them and fix them soon by compiler, code analizyer, test apps and developers. What's on the stake? Unstable efl has coming from the misunderstanding of code history, whole logic sequence in real complex usage and api concept changes. Obviously, we need official designated maintainers in efl, at least those maintaining parts should not be broken any more. Plus, as we know, UI is not a single functional stuff. It's applicable. unit test or single function test is not enough. Even we human cannot imagine or expect how our changes will bring broken behaviors from this complex world. few but still, we have those efl apps and active app maintainers- rage, terminology, eruler, ephoto and enventor etc Actually they are not enough number of unit but unless we try to keep them alive, well, who wanna untrustworthy library and write apps using it? I wish efl developers should not satisfy with just unit test / test apps such as elementary_test. Before a new version release, additionally, we should get approval by more practical apps whether they have any compatibility issues or not. On Tue, Jun 26, 2018 at 11:11 AM, Simon Lees <sfl...@suse.de> wrote: > > > On 26/06/18 04:36, Mike Blumenkrantz wrote: > > Hi, > > > > Do not attempt to use Eflete. > > > > I was attempting to examine a related issue from phab today on my test > > machine and Eflete somehow managed to delete nearly EVERYTHING from my > home > > directory. All my .directories, all my source trees, everything deleted. > > > > Fortunately, this was only a testing machine and nothing other than some > > local configs were lost. > > > > DO NOT USE EFLETE. > > > > > > Regards, > > Mike > > Last time I tried to use it, it wouldn't build against the current > stable efl release so I gave up, which is a shame because when it was > working well it was a really useful tool. > > -- > > Simon Lees (Simotek) http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Regards, Hermet ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
