It seems like you have two main points here: 1) The review process for components should require the approval of "maintainers", or people who are experts in a given area, and not just anyone with commit access.
I agree with this idea. While it would certainly be nice if everyone could review every patch, not everyone has the same level of expertise in every part of the codebase, and having someone without enough knowledge of the code doing review on it can lead to problems. I think the next step for this would be to create a proposal with some initial "maintainers" for given parts of the codebase and set up herald rules to automatically add them as reviewers when patches are submitted for their areas. Then we can see which areas need more coverage? 2) Testing is still inadequate, and applications need to work with versions of EFL that are about to ship. This is also a good point. There are cases where applications are broken by changes in EFL, and we should avoid this. The problem, however, is that application-based testing will always be a bit random due to differences in user configs and distro setups. We should resolve this by continuing to improve our unit testing as well as working to integrate Exactness into the test process. As coverage of these two types of testing increase, the difference between "testing by running an app" and "testing by running 'make check'" will lessen until eventually only 'make check' should be needed. This also requires some work from app developers: any time their app is broken, they should ensure there is a clear report, and a unit test of some kind should be added to ensure that the issue does not occur again. On Mon, Jun 25, 2018 at 11:54 PM Hermet Park <hermetp...@gmail.com> wrote: > 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 > ------------------------------------------------------------------------------ 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
