Hi guys, I think a little context may help here - please take a breath and consider each others motivation before contradicting further.
William, EFL is intended as a cross-platform solution. Apps built with it should work on different platforms and front ends without re-compiling. We are moving to binary distribution (at some point, some how) (see previous conference topics on "Marrakesh") so having binaries for each configuration option is probably not maintainable. It is clear that we have some projects that are not maintained and really appreciate any help we can get to move things forward. However cloning a repo to an alternative remote does not make that official. The out of date codebase in git.enlightenment.org is still the official repo - and until we manage to figure a permanent change (access or relocation) it remains the responsibility of the forker to pull any upstream changes. This is not meant to be onerous but it's pretty much how things are. Raster, William has been a huge help in progressing some of our projects whilst learning how EFL and the E team work. It is, as we have discussed before, a very steep (and large) learning curve that we need to find a way to support. I think that we should learn from every trouble or confusion that is encountered in on-boarding so we can make it more attractive to new developers. It does seem like we could help folk further develop some of our established apps if we were able to allow access to just one app and/or to have external remotes for those things that are not "core" to the EFL experience - what do you think? One other thing that has come up in conversation was roadmaps and whether it would be easier for folk to get a grasp of our direction and reasoning if we had a consistent message for folk to digest about where we are going? Thanks everyone for contributing to this conversation - it is really helpful to understand how we can better get more people contributing to our apps or EFL that have not been involved before. Cheers, Andy On Sun, 14 May 2017 at 00:52 Carsten Haitzler <[email protected]> wrote: > On Fri, 12 May 2017 11:10:14 -0400 "William L. Thomson Jr." < > [email protected]> > said: > > > On Wed, 10 May 2017 15:37:57 -0400 > > "William L. Thomson Jr." <[email protected]> wrote: > > > > > That is what I am used to from when I was a Gentoo developer years > > > ago. Once you get commit access, it is unrestricted. It is expected > > > to be respectful. If you touch another's stuff get permission etc. > > > > Kind of funny to mention this and the timing. This is just an example it > > is minor. But does give me a bit of concern about working in shared > > repositories without checking with each other. > > > > A user reported a known issue with ecrire under Wayland on IRC. I have > > it on the Readme[1], and its an open issue[2]. Which I would think > > anyone running into such, or looking to address would take the time to > > look for such. Rather than any of that, sadly Raster went and commented > > out the code. In the inactive repo. > > > https://git.enlightenment.org/apps/ecrire.git/commit/?id=20983dc2a2c737620c7aaf8f45d47d5e84e71334 > > seriously? you really need to re evaluate some of your perspectives. > > > I had just last night merged my branch into master on my Github > > mirror/clone to prepare to sync the Englightenment ecrire git repo with > > my Github one. This commit will cause issues for that merge. It can be > > reverted/fixed. Without such merging my changes will be difficult as > > that effects the very base. All my work was based off the commit before > > the one raster just did. That commit will effect my changes to that > > file and make merging difficult. Really best for no commits to be made > > till my work was merged back in. > > welcome to conflicts. also known as "that's life" when you share a > repository > and you are not sole king of the hill. > > > This is not really a quick fix and I have been spending time on the > > matter. There is an open task which is related[3]. That one references > > an older for the exact same code and purposes opened by Tom. > > > > I had already coded a more proper fix that has the same effect of > > commenting out the code by not enabling a IF DEFINE condition. > > > > cmake -Dwayland=true . > > > > At least that does not remove the function from ecore x and wayland. > > Commenting out code removes from both. If my solution was not good, > > commenting out the code is worse. > > oh seriously? you think that's a proper fix? it's far worse than my "just > comment it out". you make a binary that is non-portable between x and > wayland > and that should never really happen for any regular app. they should "just > work" when executed under ether display system. > > you want to give me a lesson in how efl works, should work, and apps > should use > it? > > > Anyway it is minor. This is intended to be a community project. With > > others collaborating, etc. Though still has to be some coordination or > > checking with each other before proceeding with commits that may cause > > issues, additional time, work, etc for another. > > > > 1. https://github.com/Obsidian-StudiosInc/ecrire > > 2. https://github.com/Obsidian-StudiosInc/ecrire/issues/2 > > 3. https://phab.enlightenment.org/T5476 > > > > -- > > William L. Thomson Jr. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- http://andywilliams.me http://ajwillia.ms ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
