Yea, at last :-) :-) :-)
Me and Freddie were trying to explain this all the time:
1. I dont want to change the commits and their order because things can
stop working, changes are step by step and on purpose, all changes are well
described, commits are granular to be easy to understand. Resulting code
will be the same so I prefer to put that time on core development instead
patch edition.
2. The code is a good starting point, not the final solution, its working
so it can be used by the users while developer can make a better solution
out of it. I have noted that internals redesign is the next step - that is
making reset code jtag independent, using mpsse driver, creating layers,
adding new transport and bus support, etc etc.
I dont want to expand the code that you already consider obsolete, and I
know better solutions can be achieved, instead I prefer to put this time on
core development, using new functionalitie and fixing stuff. As for now
month has passed for an idle discussion while I had some free time to make
some coding, now I need to wait for next free time slot.
Maybe some important assumptions were lost as the discussion started in
Gerrit and so Spen's attitude 'do not submit' and my 'do not change' got in
here straight away. This is why I dont really like the idea to make
development inside Gerrit, which should be only patch filter, review and
cleanup tool. Patches should be edited not more than lets say 5% on Gerrit,
otherwise rejected, editing, rebasing and reviewing 20 patches at time is a
disaster. We have mailing list where discussion should take place, we have
GIT where development shold take place. Otherwise we have tremendous
misunderstandings like this one. This should be a lesson for future :-)
We have two choices now I guess:
1. Add my commits and mark ft2232 obsolete, then make last release of the
0.x.y series and start working on 1.x.y series, where is no ft2232 driver
and we have Adapter layer implemented as well as others internals
reorganization. This gives a working solution to the people straight away.
We put a thick line on the past and set course for future. This must happen
one day, why not today. I prefer this approach and suggest this all the
time.
2. We reject/waste all my current work on swd and continue to work on
0.x.y. I will work directly on modification of Adapter layer, interface and
transport to fix the internals and the additional outcome would be the swd
transport working. This will not give working solution to the users for
next few months or years, a lot more commits will show up than I have now
proposed, lots of them will be a regression for some time. Patches should
be sent directly to gerrit rather than on be worked on a separate fork
until goal is achieved. You seem to prefer this one..?
Best regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
