REALLY Thx to understand my point of view ! I never wanted to minimize your help on this project. I just used git log from my memories, to explain why I do this patch in this way (Without taking care futur review of others devs). In september, I know you have worked before, on entrance, to fix it. And I told you at this time, I'll be happy to merge your changes after my commit, based on old source code. Because, I know it's a lot of work, to understand and dissect source code changes. In the respect for everyone, I will try to reduce the noise in the futur, that I can do with this kind of patch.
Don't worry when entrance will be ready. I would do a big noise, in order to encourage as many people I can, to test it. For systemd, my plan is to work on next month, then I could help you. But today, I don't use this init system :(. With my best regards 2013/10/31 Carsten Haitzler <ras...@rasterman.com> > On Thu, 31 Oct 2013 00:51:21 +0100 Michaël Bouchaud <y...@efl.so> said: > > > I will try to find my best words. > > Sorry to annoy you with a huge commit. But as I say before, I'm the main > > dev of entrance and the only one to take care about it. And I do it in my > > free times, as my contribution to the efl libraries and enlightenment > since > > a long time. > > Raster or cedric have made some contribution to entrance before. But it > was > > a long time ago. The last diff I see, from another than me, is from > raster, > > where is a diff is on a pam file (not C code). Raster don't see I > provide a > > file for debian-ubuntu pam... > > umm actually i did a lot more than that: > > e51ff8cd2501304d3cee33621a3e520204e4f4b9 > 38f369b419e9fef8090dc75b1321fb3d0a61c07a > c05de4d019d590157b2edabce1aa808e63f28da1 > 16d33cdc4df0cc9e5063bb9c8a0b5fb77d4dc7bc > 530e75cf7453398c059f3d6bc487766b83591a6d > 688276f3259eee7da29a3b7e046b0ab2c33365fd > 4d4cdc967c08fcd126704ece6b2d2394b91f1b22 > 981bf81dbb1820e2e74536926ab00336b58b43a1 > > all on sept 4. :) but either way - not a lot. :) > > > So I take this into account that an advanced user, who don't notice I > > provide this one. So I change my mind and today, I provide a debian pam > > file in first. (the second pam file is for gentoo or arch. Where I think > > user are welcome and get used to do some patch or custom cp for things to > > work, instead of ubuntu users...). > > But this is not the problem here. I just want you point out, I have some > > users who use entrance everyday and welcome to have the last revision to > > test it. We have migrated from svn to git. OK. They do it, and since I > > still have about 10 mails each months for entrance... > > as such entrance was in svn before and it's in git in the same way. thats > how > it was and how it continues. i think here is a little too much focus on > "rules" and what i see as a desire to build more bureaucracy that "everyone > must follow the rules" "fill out form x" "get approval y". it's heading > that > way. and that's a good way to lose developers. just leave entrance alone. > let > it do its thing. if yoz wants to mess with it - fine. until it's up on > enlightenment.org as a download tarball and something that the wider > project is > pushing/supporting, it doesn't much matter. ignore the commits on it unless > *YOU* use it and those commits affect you. :) the day yoz wants to push > entrance to become a released/up for download thing... lets deal with it > then > and maybe bring entrance under some more control. > > > Now I have 4 choices. > > - First one, try to do atomic commit to pleased you and have some review > > from nobody...(maybe cedric for some commit not all, where he will say > > nothing...). As I said before, I don't want to spare my time for that. > > - Second choice, don't do atomic commit... and nobody can (want) review > me. > > But I will annoy some people with my huge commit (where this people can > > configure mailing box to ignore it as said by kuri). > > i think just filtering (ignoring the commits) is the best way - if you > don't > care about the project.. ignore its commits. > > > - Third choice, as second choice don't do atomic commit, but my project > go > > in my dev dir. Here my user will be annoyed, because he don't be noticed > by > > recent changes and I lose my futur audience ... > > - Fourth choice, don't do atomic commit... and open my own github. And I > > will annoy my user for a last time and don't boring you again. > > i think this is the worst option. i think just keep entrance exactly as it > is. > keep doing your work. i sure am not going to review every commit to it > even if > they were perfectly scripted and gold plated with cherries on top. it's not > important to at this time. if i use entrance, i will whack at its code to > make > it work if it does not. if a feature doesn't work right - i'll fix it. if > it's > missing something i need - i'll add it. pretty simple. commits can always > be > reverted. > > > But in last, if the last choice comes to be the best one. I will be very > > sad to go away from this repositories, because I think entrance could be > a > > good publicity. Further, entrance works like a charm for years, and I try > > to not b0rk it... > > hmm in sept i had to fix a tonne of stuff where it segv'd all over the > place > and really did not work. :) thus my commits. :) i had many more changes i > had > locally that conflicted with changes you made and i dropped them. :) > entrance > imho is on its way there to being "ready to go" - but not there yet. :) > > > In last, but I can't say "ok, I go to my own dev dir and don't boring you > > again" here. But I understand your point of view. So, I let you assume > your > > remarks and futur decision. I'm not the one who have coded 90% percent of > > code of efl libs so I can't be a dictator to make some decision. I just > > want to have some arrangement with you on this point. > > > > PS: I never be remunerated for my contribution to efl libs or elementary, > > if I have succesfully imposed the efl and enlightenment in my last jobs. > I > > always do my dev on the efl libraries on my free time as I do for > entrance. > > If I had never considered to improve or debugging efl libraries and > > elementary, surely entrance would be in a better state today. And > > elementary in a worse state... as the efl libraries. Please take this > into > > accounts. > > > > Regards > > > > > > 2013/10/30 Guillaume Friloux <guillaume.fril...@gmail.com> > > > > > Hello guys, i dont put quotes as there would be too many things to > quote > > > and i want my mail to be short. > > > > > > Entrance is used by a bunch(maybe i should define 'bunch') of peoples, > > > already using this git repo. > > > The fact that yoz is the only active dev on it ATM doesnt makes it a > > > personnal project. A project is defined "personnal" when there is only > > > one user, not one dev. > > > In my opinion, this project has enough users to be in /misc/ or /apps/, > > > and not be isolated in /devs/ repo (or start to also move ecrire, > > > ephoto, etc). It is also a very interesting project that needs > audience, > > > hidding it in /devs/ is BAD. > > > > > > You guys are asking rules to be respected on a project you dont even > own > > > (leading to "lets put this out of repos"). > > > If his patches bothers you, while you are not even working on it, you > > > can configure your mail client to filter those commits and mark them as > > > read instead of making changes that would affect michael and all the > > > entrance users. > > > > > > Michael already does atomic commits on all the /efl/ patches he does, > so > > > he doesnt have to be told about that. > > > If you join his project and start working on it, then im pretty sure he > > > will start to do a lot of nice things for you, even explaining his code > > > and answering every question. > > > > > > Re-reading my mail, it can seem rude, but its not, its just 'clear'. > > > > > > > > > > ------------------------------------------------------------------------------ > > > Android is increasing in popularity, but the open development platform > that > > > developers love is also attractive to malware creators. Download this > white > > > paper to learn more about secure code signing practices that can help > keep > > > Android apps secure. > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > -- > > Michaël Bouchaud (yoz) <y...@efl.so> > > > ------------------------------------------------------------------------------ > > Android is increasing in popularity, but the open development platform > that > > developers love is also attractive to malware creators. Download this > white > > paper to learn more about secure code signing practices that can help > keep > > Android apps secure. > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- Michaël Bouchaud (yoz) <y...@efl.so> ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
