On Thu, 31 Oct 2013 00:51:21 +0100 Michaël Bouchaud <[email protected]> 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 <[email protected]> > > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > Michaël Bouchaud (yoz) <[email protected]> > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
