>> Sounds like you're currently not interested. Too bad. I'll leave the >> branch on the public repo in case you change your mind. > Erik, I really appreciate the time and energy you've provided to Apache > Flex. However, it feels like every time I question a contribution, you > threaten to quit. The vast majority of the lines of code you have submitted > are in the repo. Of the 100's of lines of changes in the goog.events > branch, I am only questioning a small percentage of them.
Well, the feeling is mutual, it's like every time I try to make a contribution to FlexJS, you tell me it's not what YOU would do if you'd worked on it. That's not a review on technical merits, that's personal preference. Technically, the 'goog.events' donation (which is more than purely the implementation of 'goog.events') is valid - as it faithfully plays back the FlexJSTest_again example - and it improves and simplifies the framework. It will also simplify component and framework implementations going forward. The only cost is 6k increase of the final deliverable... > We are supposed to work together and to me that means that we have to be > willing to accept reviews. I think I am keeping the review on a technical > level as we are supposed to at Apache. If you feel personally attacked then > please point out what language I am using that feels like an attack and > accept my apology. I accept reviews, certainly. And if a valid technical point is made, I'd even consider reverting, as is the Apache Way (tm). But I haven't yet heard a technical point. If it boils down to it that in this day of universally available broadband connections a one time 6k increase in the size of the deliverable is considered a "technical issue", well... that makes me feel like quitting. Nobody is fighting a highly unoptimised 8k CSS file that was just added to the release deliverable, because it adds functionality that we like and want. Why would we block that based purely on the fact that it adds 8k? > It has gotten to the point where I feel like I should never review your > contributions and just let you check in anything you want. Maybe that's > what Apache means by "community over code", but that doesn't feel right to > me. "Community" means compromise. That means that you sometimes will have to accept code and contributions that differ slightly from - or may be totally opposed to - what you would produce. Working together involves a level of trust. I trust you when you add new features or work on the framework. There are (should be) tests that prevent your work from breaking something in mine. I don't question (review) every commit you make, I don't second guess your solutions, I trust you to work on this to the best of your ability. If you don't break it, I won't veto it. I expect the people I work with to give me the same consideration. >> If I decide to keep contributing to Apache Flex at all, I'll focus on >> developing the VanillaSDK for AS->JS, a library that promises to have >> a much shallower learning curve for application developers than >> FlexJS. > I hope you continue to contribute to Apache Flex, but please tell me how I > can review your code without making you want to quit every time I disagree > with you. Explain to me what you mean by 'review', we seem to have different definitions. In mine, review is 'check if it works and doesn't break anything', with the added benefit that I keep up to date with changes in the code. This 'goog.events' contribution offers new functionality, improves the current implementation and generally makes life easier for the few contributors this project has. If that's not a valid and worthy addition to the project, I don't know what is. If review means you'll be looking over my shoulder and question every design decision I make and analyse the validity of every line of code I contribute (yes, I'm overstating to make a point), it makes me lose my motivation and since I'm doing this on my own time, as a volunteer, for no reward other than the pleasure of doing it and the feedback of the community, then yes, I'll threaten to quit when it happens. Tell me where my code is wrong or could be improved and I'll gladly use the opportunity to learn from your comments. Tell me that because a contribution I offer is invalid purely based on a negligible increase in output file size, and I'll object - and given I'm me, I'll be probably be all drama queen about it, too ;-) EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
