"Ulf Samuelsson" ulf.samuelsson@atmel.com wrote:
No, this is not the way we work. We submit patches that can be reviewed, not chunks of code that the reviewer has to anayze with additional, unnecessary efforts.
Antonio submits a working patchset which is structured in the same manner as existing boards. Haavard has a different goal which is important, but less urgent than other things.
What the hell makes you think that your goals are so much more important than mine (and everyone else's for that matter)?
It's much easier to get the drivers merged now rather than later. I did actually do a quick diff and I saw at least three minor fixes reverted, so the drivers have _already_ started diverging. Do you think they will somehow be _more_ similar if we just keep them in the same tree for a while?
Besides, there's a very real possibility that the drivers will never be merged since we're all busy with other stuff.
Btw, apart from a couple of relatively minor things, I think the diff as a whole looked very good, so that's not at all what I'm complaining about.
Why not get the Diopsis support in first, and then do the merge afterwards.
Because this is NOT the way it works. Please stick to the established rules.
Which rule is you referring to?
Since Haavard wants this merge, then I suggest that Haavard takes the existing patches from Antonio and reworks them ASAP, testing them out on AVR32, AT91 and Diopsis, and resubmits the patchset so that we have a working common driver and working AT572D940DF board support.
Ulf, if you keep insisting on that attitude, you'll never get anything merged. This is _so_ not how it works.
I can certainly help Antonio get the patch into an acceptable state for merging as well as test it on AVR32, but demanding that I set up toolchains and test every single Atmel board out there is just totally unreasonable.
Besides, the driver was originally written by me. Isn't it fair that Diopsis gave something back by making it usable on more than just their board?
Haavard