On Sat, Jan 26, 2013 at 7:07 PM, Peter Stuge <[email protected]> wrote: > But openocd.git is not the place for proof of concept code, > it only includes finished work - so that it can be released > at any time.
Not sure if there is any "finished work" anywhere, not even in the openocd.git. My code is not a dirty hack, its clean working good starting point. There must be some starting point, and the progress, then some goals, then further developments, etc.. I can see some contradictions in your argument - you want the code to be finished, you want small changes, you want people to test it, you don't want to integrate it, etc. I don't know where this will lead... I like that you are not accepting all random patches and want to keep the organization clean, however I thouhgt GIT is for the development, that is expanding software step by step, not just keeping the release code. What is the other way to add such big changes to the project when the change is ready? Maybe, if you don't trust my changes (which is reasonable assumption), two of you as the most advanced developers should simply sit on the changes, have some time (one month lets say) to analyze it line by line, make a problems list, make a todo list. And then we can discuss over the code. I would prefer to talk over the code rather on the ideas on what thinkgs should be because most ideas are simple in the head and hard to code being restricted with existing design... >> It would be nice to get some support at this point. > > Yes, I think that's very reasonable, and well deserved. But as you > know, many if not all OpenOCD contributors are busy, which makes it > very difficult to process a huge set of commits - as opposed to a > small set. This is one functional change - no matter is there is more smaller patches that change file by file (as you like?), or less patches that group the changes (as I like) - the result will be exactly the same. This is why I suggested to concentrate on the core development rather than patch editing. The change is big, there must be more than one line of the code. Please note that I only changed one thing in existing structure of OpenOCD and that thing was experimental anyway. >> If anyone thinks that some things can be done better, feel free to >> code and show the ideas working. > > On one hand you're perfectly right, on the other hand it is often > significantly more efficient to discuss and think about ideas than > to implement and test, with the minor catch that discussion requires > working communication. This is why I am communicating my will to change internals and the way I like it to be done (separate thread), there is a time for discussion and argument between different point of view. The goal is to create a better tool. I prefer to talk over the code, because anyone can write anything on the list, this takes time to be written and then read, while this time also can be used to create code that will prove the idea, otherwise its just trolling. If the code cannot be created easily then the idea maybe needs to be reconsidered. I spent lots of time to invent and implement ideas that will work and does not change existing OpenOCD structure - If things were solved that or another way, there is a reason behind that - the most probable reason is non-invasive approach, backward-compatibility and elegant solution. If things were solved that or another way, that's probably the other way did not bring the final solution any better. Writing the code yourself will show that and I want you to understand that :-) I guess you want to make too much changes at once. Lets divide the work into steps and do it step by step. We cannot do all of the stuff at once in the Gerrit. I really think Gerrit should be just a filter for patches and some buffer so MINOR changes can be introduced (i.e. typos fixes, etc). Gerrit is not a GIT, its not branch, but you already know how I see this - you shifted GIT/MASTER/HEAD function info Gerrit which I don't really like. If the patches are not as supposed to be, they should be simply rejected and sent again in another form. I see Gerrit as patch cleaner and review tool, not the development branch of the project. Here is our disagreement. Btw. what are the exact problems with my patches/commits, except commits needs to be reordered (which makes no difference to me)? I did not get any precise list of remarks to the code, and the ones showed up on the list are totally out of the scope of my changes. This is why I am just waiting to see what was wrong and what was the solution ;-) 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
