19.03.2013 16:01, Lucas De Marchi kirjoitti: > On Tue, Mar 19, 2013 at 8:55 AM, Kai Huuhko <kai.huu...@gmail.com> wrote: >> 19.03.2013 05:48, Lucas De Marchi kirjoitti: >>> On Mon, Mar 18, 2013 at 5:57 PM, Kai Huuhko <kai.huu...@gmail.com> wrote: >>>> Referring to: >>>> http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 >>>> >>>> Next time do notify us, preferably beforehand. You broke our build with >>>> this commit. >>> How the hell I would know *you* were working with it? >> http://git.enlightenment.org/core/efl.git/commit/?id=61ca9d550d705ea21afbe88a0af3e3cba2515314 >> "First of all, if it's not tested it shouldn't be committed." >> >> This tells me you actually went and read the original commit message: > yep > >> http://git.enlightenment.org/core/efl.git/commit/?id=8ecd30d578ebac46bbdf5f6d5c0b7cad1187f84f >> "Add a new API to edbus to let it create an EDbus session from an >> existing DBus connection. This is needed by the python bindings, was >> done the same way in edbus1, so it should fit here also >> NOTE: I did not test this yet, and I'm not into the edbus code, so I >> please who know the code to give a look. thanks > particularly this part. > >> NOTE2: I don't think this need Changelog and stuff as we are probably >> the only users of this function, let me know if i'm wrong" >> >> and most likely saw the code comment: >> >> * @note this is a low-level function, it is meant to be used by language >> * bindings, don't use unless you know what are you doing! >> >> So you very well knew it was being used by the python bindings. > > yep... so you added a wrong API to edbus that according to your > comment is not tested yet, but will be used by the python bindings. Do not avert the matter from the point. > >>> And since it was >>> wrong, breaking it was really the best option. It's like a "HEADS UP, >>> you are doing it wrong". >> With the aforementioned knowledge the best option would have been >> notifying us. You can use strong language and bash us over the head with > the same way you notified about adding the API. AFAIK we did, see below. > >> virtual trout if you like but don't go and pull the rug from under other >> peoples work when you have other options available. I don't mind if the >> breakage happens by incident. But if something is clearly mentioned as >> being used by other EFL projects then you should either fix those other >> things yourself or notify the people working on them. > I'll never fix other projects if they introduced a bug in the library > in order to create a bug in their software. Sorry if this bothers you, > but I can't babysit all projects in e-svn or wherever they are hosted. > As one of the authors of edbus I can however fix whatever is there. > In a sensible workflow you would submit your change in edbus for > review so you wouldn't actually depend on this API since the > beginning... you decided to take the shortcut and commit, so I did. Since I did not personally commit or develop the code in question I cannot speak authoritatively of the process that was taking place when this was added, I did however observe the conversation taking place on IRC where the code was reviewed by one of the ProFUSION/Intel OTC folks. So, according to my knowledge the code was reviewed and accepted.
I am speaking here as someone whose software project was broken by your commit. I am upset about the fact that the problem nor the fact that you resolved it, in process breaking our stuff, was not communicated to us by you in any way except in the commit message, even though you perfectly had the means to do so. You should be aware that language bindings for the library you are developing are in the immediate perimeter of your own work. Having an arrogant attitude and being disrespectful towards people who contribute into your work out of their generosity and kindness will not go over well. > >>> And as said in the commit message, we should be careful about adding >>> APIs like this. >> Yes I completely understand and you are right that it was bad, which I >> am not arguing against. We were trying to be lazy and replicate e_dbus >> (v1) bindings functionality, where the actual heavy lifting is done by >> python-dbus. It was working but obviously edbus did not like having >> foreign objects and rightfully complained with error messages. >> >> We'll come up with a better solution and next time we'll ask more people >> for review if new C API is to be added. > ok > > Lucas De Marchi > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
