2013/3/19 Michael Blumenkrantz <michael.blumenkra...@gmail.com> > On Tue, 19 Mar 2013 21:51:18 +0200 > Kai Huuhko <kai.huu...@gmail.com> wrote: > > > 19.03.2013 19:38, Lucas De Marchi kirjoitti: > > > On Tue, Mar 19, 2013 at 12:40 PM, Kai Huuhko <kai.huu...@gmail.com> > wrote: > > >> 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. > > > I am not. What I did: > > > > > > git remote update > > > git log HEAD..origin/master -- src/lib/edbus > > > > > > And there was a broken commit there. And a message saying it was a > > > NOTE saying it was *not* tested asking for someone to take a look. I > > > did and since it was wrong I reverted it. > > > > > > > > > > > >>>>> 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 > > > It was wrong - I asked on IRC if Dave was around - he wasn't. Then I > > > wrote a lengthy commit message explaining WHY it was being reverted. > > > As I said, I consider this the HEADSUP you were asking for. If you > > > don't agree, sorry, but right now this is how the project is being > > > handled. There's no "notification beforehand" - if you were deeply > > > depending on it you can carry this patch with you until you moved to > > > another implementation. > > > > > > What did you want? An email asking for you to fix the broken stuff? > > > What would happen if another project, unrelated to yours, started > > > depending on it? Would you send them an email, too? How would you know > > > the projects that were depending on it? > > We do have this list for that kind of communication. There is no policy > > that prevents one from doing so, nor is there really one that encourages > it. > > It's considered common courtesy (read: expected) that anyone committing to > a project that they do not own or directly maintain will ask the owner to > review/approve their work. There is no such rule for owners/maintainers for > obvious reasons. >
Totally agree, but of course we (me and kuuko) have done it. This is how that commit has taken the way to git: 1. we asked in chat to one of the edbus2 author (k-s) how we can implement the py bindings. 2. the author say to implement the reverted API 3. I have written and committed the new API without testing on my machine because kuuko tested it 15 minutes later. 4. the later tests prove that the api was working well (seems) 5. another edbus2 author reverted the new api without asking :( So I think we have taken all the right (expected) precaution before committing the new API. saying that I agree that the new function was somehow bad (still I didn't know about your plan to remove the edbus dependency from edbus2), but as the author suggested it i have committed it. The next time we simply ask you (lucas) to discuss better a commit/revert that brake other stuff. Searching for me in chat and not finding me is not enough, you should have written a mail to this ml to find a different/better solution) Btw, the api is now gone and we disabled the building of py-edbus for the moment... do you have a different solution? do we have to implement ALL the edbus2 functions? or maybe we can do the main loop integration in py-edbus without using edbus2 at all? I hope this mail have solved all the misunderstanding betweens developers and sorry if I committed a wrong API. Peace and love :) davemds > > > > > I understand now that you did not want to see anything broken in your > > work and reacted immediately. You did what you had to do. > > > > > > > > >> 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. > > > I think you are overreacting on it. I comprehend you got pissed > > > because you were working with the assumption that this function was > > > correct. But since it wasn't, the best thing to do was to remove it > > > ASAP, before others started depending on it. In no moment I was > > > arrogant or disrespectful to you. Sorry if it sounded like that. > > I am sorry for reacting so strongly. > > > > > > 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
