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. > >> 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. > 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. >> >> 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
