On Fri, 12 May 2017 11:10:14 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> said:
> On Wed, 10 May 2017 15:37:57 -0400 > "William L. Thomson Jr." <wlt...@o-sinc.com> 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) ras...@rasterman.com ------------------------------------------------------------------------------ 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
