On Sat, 27 Jun 2015 12:01:16 -0400 Michael Blumenkrantz <michael.blumenkra...@gmail.com> said:
> On Sat, 27 Jun 2015 14:11:29 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Fri, 26 Jun 2015 16:19:17 -0400 Mike Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > > > Thankfully, it seems you didn't end up pushing your revert back upstream > > > and the issue is now resolved. > > > > ummm... oh crap. you're right. oops. i didn't push. > > > > > It would be great if we could step back from this "instant revert" culture > > > that has been created since the move to git. Just because it can be done > > > doesn't mean that it should; it's a very reasonable thing to do a local > > > revert (like this) and then raise an issue about the commit in question. > > > This preserves repository history and makes it significantly easier to > > > bisect things when there are fewer "revert XYZ" -> "revert 'revert XYZ'" > > > chains needing to be followed. > > > > 1. i pinged you on irc. you did not respond. so you were not around to > > discuss, and an email would thus not elicit a response in a timely fashion > > either. > > I appreciate your attempts to contact me prior to reverting. > > > > > 2. the point of reverting is to ensure OTHER PEOPLE are not sitting here > > bitching all day about their desktop being broken so badly that it's > > actually unusable. you expect each and every person to work out their own > > personal private reverts? it has been a point of pride that our cvs/svn/git > > has remained relatively usable at all times. this bug made e unusable. i > > made a call because it was SO BAD that it had to be reverted and people > > OTHER than me WILL be affected as well as it is the default pointer focus > > mode. the longer it stays broken in git, the more people are affected. > > > > i think you need to get some perspective on this. this is not a revert > > because of a typo or some small irritation in behavior. repository-history > > comes a distant second place to having code not break so badly that it's > > unusable. this is a QA, support and stability matter. > > > > i think that YOUR attitude on this is questionable. it has an undercurrent > > of arrogance. yes - i am calling you out on this. if your response is > > "please don't revert and discuss" and you expect all the people who update > > from master to suffer while they wait for you to finish sleeping or > > whatever (which is perfectly normal, so nothing wrong with that), as > > opposed to "oh oops. sorry. that was bad. thanks for that. fixed it now", > > then that tells me that you prioritize the beauty of commit logs over the > > pain of users and developers, and that is arrogance. you matter more than > > they, and when someone else spends the effort to fix things you would > > prefer people suffer than hurt the "beauty" of logs with a revert. please > > think about this carefully. > > > > this isn't an instant revert culture here - i have NOT reverted your keysym > > commit because it isn't hurting anyone at the moment, for example. i make a > > call that when something is bad enough it has to be fixed whatever way > > possible ASAP. i made that call here. > > You have your perspective and that's fine; you're looking at this as a > couple of incidents related only to me, and I'm seeing it as a microcosm of > the developer ecosystem as a whole. > > In my view, the workflow since moving to git has changed from "someone > introduced a bug, maybe I can help out by fixing it" to "someone introduced a > bug, better revert every possible commit". It's a fundamental shift from being > collaborative to being combative in our usage of SCM, and I know I'm not the > only one who has noticed this. Simply checking over the commit logs will show > a staggering increase in the number and frequency of reverts in every > repository over the past couple years. > > At no point have I ever said (except as a joke) that my code is always > flawless. I have no issues with criticism or reverts, except when it subverts > or replaces actual cooperation between developers, which, in my opinion, is > what has happened to us. in this case this doesn't imho. i tried to contact (co-operate) but due to no response within that hour or whatever a fix wasn't likely to be timely. i actually bisected the commit and read the diff. i read all of the diff and nothing jumped out at me as the cause so i could do a quick fix. i had to make a call. let it sit broken for possibly another 2-12 or so hours, or revert it with sufficient information as to why it needs a revert. i believe the log and email contained easily sufficient information. in my book that is communication. a log by itself would not be. the email is the explicit heads-up. i would have preferred that it be fixed without a revert, but i was literally sitting there with a broken system and beginning to swear every second word just trying to function as normal. sure... i can roll back myself to before the commit but i realized that what i was experiencing would be widespread soon enough without a fix. as i said - it's a judgment call. not a "just revert everything i don't like". i've said this before - reverts imho are justified if the problem is bad enough. bad enough is a combination of how long it'll take to get a fix into master and the severity and impact of the issue itself. if efl literally stopped compiling for all people and no quick fix was available, a revert is justified pretty much immediately. a non-compiling efl puts all developers working on it in a bad spot as they have to rebase to push and thus they get a broken build tree they can't build or test anymore. that's a low barrier of entry to a revert. if e just segfaults immediately on start after a commit and the bug/change is not obvious/easy and quick to find, a revert is justified. it goes from there progressively through more grey area. don't take any and all reverts as some "revert happy culture". it's a tool provided by things like git because sometimes it is really the best thing to do at the time. it's done more with git because git has made it far easier to do vs svn, thus it is more likely to be used. this does not make it a "bad thing". it is a tool that is easier to use to keep the tree more stable FIRST if needed then let the person know what's going on once the emergency has been dealt with. > > > On Fri, Jun 26, 2015 at 3:34 AM, Carsten Haitzler <ras...@rasterman.com> > > > wrote: > > > > > > > On Thu, 25 Jun 2015 17:30:43 -0700 Mike Blumenkrantz < > > > > zm...@osg.samsung.com> > > > > said: > > > > > > > > sorry - i had to revert this due to a pretty bad behavior bug this > > > > commit introduced. see my commit log in the revert. i pinged you on irc > > > > (zmike) but no > > > > response, so i've had to do this to at least keep e working until this > > > > can come > > > > back without this break. :] > > > > > > > > > discomfitor pushed a commit to branch master. > > > > > > > > > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=2b38147c43270815ef71726d8700703968429d90 > > > > > > > > > > commit 2b38147c43270815ef71726d8700703968429d90 > > > > > Author: Mike Blumenkrantz <zm...@osg.samsung.com> > > > > > Date: Thu Jun 25 19:55:37 2015 -0400 > > > > > > > > > > add hooking for WL_SURFACE_ID atom on XWayland windows and > > > > > composite > > > > them > > > > > > > > > > in order to maximize the amount of reused code the following > > > > > details > > > > the > > > > > current process for xwayland compositing: > > > > > > > > > > * get map request from window > > > > > * force reparenting > > > > > * show window > > > > > * await WL_SURFACE_ID x11 message > > > > > * move x11 client data + pixmap onto corresponding wayland client > > > > > * business as usual with wayland compositing > > > > > > > > > > this is pretty similar to the method of the reference code in > > > > > weston, except that there's no x11 compositor in weston > > > > > --- > > > > > src/bin/e_comp_wl.c | 21 ++++++++-- > > > > > src/bin/e_comp_wl.h | 34 ++++++++++++++- > > > > > src/bin/e_comp_x.c | 119 +++++++++++++++++++++++++++++++++++++++++++ > > > > > + +------- src/bin/e_comp_x.h | 8 +++- > > > > > 4 files changed, 161 insertions(+), 21 deletions(-) > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > Monitor 25 network devices or servers for free with OpManager! > > > OpManager is web-based network management software that monitors > > > network devices and physical & virtual servers, alerts via email & sms > > > for fault. Monitor 25 devices for free with no restriction. Download now > > > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > > > _______________________________________________ > > > 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 ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
