I will not reply to specific comments but rather make some more general statements that hopefully are relevant, I know that this somewhat overlap the solicitations for process.
- During all of this I and Öyvind have been communicating patches, error reporting and suggestions. He has handled that very well even if he is a stubborn Viking from the west fiords (we know them around here, bet Egil was worse) - The disagreements has nothing whatsoever to do with formatting or whitespace policies, it is about deeply tchnical issues and about how we resolve differences of opinion. It is not about the verision handling system, git might be useful to find a release where things broke but I could do that with SVN in 30 minutes for the arm_adi code I was focusing on. - Making every nontrivial patch pass through a community process will slow development to a halt, this community does not work like that. We have more priciple discussions than discussion about actual technical merit. How many here do actually analyze the code and potential impact before arguing? I often subit nontrivial changes to the Cortex subsystem, who wants to review them ? I really would like that input, and rest assured I do have a long list of internals that should be fixed up. - I am warming to the use of a stable branch and an unstable branch. We have had small fixes reported, I have outstanding work that I would not hesitate to commit to a stable branch but presently I have put them on hold. Best regards Magnus Zach Welch wrote: > On Fri, 2009-05-08 at 17:05 +0200, Magnus Lundin wrote: > >> Zach Welch wrote: >> >>> On Fri, 2009-05-08 at 13:49 +0200, Magnus Lundin wrote: >>> > [snip] > >>>> Zach Welch wrote: >>>> >>>> >>> [snip] >>> >>> >>>>> * Are you _certain_ the current bugs being experienced cannot be the >>>>> result of other bugs that were uncovered by the removal of the >>>>> in_handler code? If they are, Øyvind just did us a service. >>>>> >>>>> >>>>> >>>> The bugs I have seen have all been caused by pushing unteted code into >>>> hede. Basically to quick and not careful enough. There were some ideas >>>> but this was not a carefull thought out architectural resturcturing. I >>>> hope to show that the old code is definetly a carefully planned >>>> archtecture. >>>> >>>> The architecture he proposes will work if cleanly implementd. >>>> >>>> >>> You are saying his ideas can be implemented successfully? Okay... the >>> only problem here is that you introduced ambiguity in the pronoun 'he'. >>> I can read your reply such that it refers to either Dominic or Øyvind; >>> your intention is not perfectly clear from the context. >>> >>> >>> >> Wrong reading, I am saying that Övinds ideas, as I interpret them can be >> implemented and made to work. >> > > Sorry. Mea culpa. > > >> Problem is that they lack more precise substance than : We shall mkove >> things and it will became better, cleaner and faster. >> > > For the most part I agree, but I also know that sometimes the best plan > comes to you after you are halfway through the patch series. > > >> He does not state how to do it or in any detal why it will be faster, >> but he is given the benfit of a doubt >> > > I gave him the benefit of the doubt because he earned it by being a > regularly active contributer to the project. Given the reaction, I > would not be as sympathetic in the future, but I have pointed out that > we lacked policies for branches prior to this incident. > > I think that policy will be changing after this, don't you? > > >>>>> * Are you _positive_ the "lost performance" will not be regained by any >>>>> other means? If it can, then that argument is insufficient. >>>>> >>>>> >>>>> >>>> It might be regained, but in that case I am positive that we we have >>>> either built the same asych callback functionality somwhere else, or >>>> trimmed the USB layer, in which case even more performance can be gained >>>> by reverting. >>>> >>>> >>> I expect the functionality to be re-implemented in a way that the >>> community will support, even if that means adding back nearly identical >>> code. If I were in Øyvind's shoes, I would rather see the in_handler >>> functionality re-implemented cleanly than just put it back as it was. >>> >>> >> True, >> but nobody has argued against reimplementing cleanly, but that is not >> retiring functionality and changing the API. >> > > One reason that I did not jump in sooner was that it has always been > clear to me that the code in question could be cleaned up. Removing it > and starting back at a stable state seems like a fine plan; replacing it > with a clean implementation would have been a better first step. > > Even assuming he used a branch, there is no way for any one person can > test architectural changes in one. Stuff would be broken in the trunk > after the merge, but -- instead of watching the progress from beginning > to end -- users now effectively receive a single patch series that > absorbs all of the changes into the tree at once. The same series of > problems will hit the tree, just now there are more revisions to bisect > and clean up. After all, most users will not take the chance to work > incrementally with the branch author. > > I honestly do not know if that will be a better process or not, given > the number of active contributors. It seems better to use an external > patch tracking or branching mechanism (e.g. quilt or git-svn) and > continue using patches. > > My biggest idea to fix this is simple: "no one is allowed to commit > their own patches; every patch must go through the list, and at least > two active contributors must publicly ratify each one to be committed." > Or something like that; I'll respond to my policy thread at some point > with a whole lot of idea like that. > > [snip] > >>>> Prime example of this is indata from ARM7 scanchain 1. This data is >>>> bitswapped. Something users that target read register funtions are not >>>> aware of. So the issuer of the Scanchain 1 scan structure tells the >>>> jtag layer about this by adding the relevant function to the in_handler >>>> field. When the data is received the code has long since move away form >>>> this function and we are in the upper layer function that simply >>>> expects a u32 value. >>>> >>>> >>> Okay. This upper layer that expects the u32... how do the functions >>> that use this value and the functions that setup the scan to retrieve it >>> relate to each other? Specifically, are those functions that setup >>> scans and those that use the results tightly coupled together? >>> >>> >> The upper layer users are general functions that does things like calls >> to target->type->read_memory(), >> The scan setup comes from calling the exact architecture specific calls >> that can read from a certain target. >> for ARM7TDMI the call chain is as follows >> arm7_9_read_memory() -> arm7_9->load_word_regs() -> >> arm7tdmi_load_word_regs() -> arm7tdmi_clock_out(). >> Here in arm7tdmi_clock_out(). the in_handler is set to flip the bits >> and then a dr scan is added >> >> >>> To start, I will assume they are. If this is the case, the situation >>> with in_handler seemed to be this: >>> >>> * We want a u32, so setup a scan to get it, with an in_handler to fix >>> the data when it comes in. >>> * At some point, jtag_execute_queue() will retrieve this value and call >>> the in_handler to convert it. >>> * Later yet, the function that needs that value uses it. >>> >>> Likewise, the new implementation may simply look like: >>> >>> * We want a u32, so setup a scan to get it. >>> * At some point, jtag_execute_queue() will retrieve this value. >>> * Layer yet, the function that needs that value can ask to retrieve it. >>> * A helper function takes the former in_handler and lazily converts it. >>> >>> >>> >> You ar right that we can do lazy conversions we have thrown away the >> information about which handler to use. The upper layer does not know >> which handler to call without doing some target specific look up of >> which handler to use. Basically going down the call chain to look this >> up again. >> > > It seems better to me for the JTAG layer to track the required > information for the caller, allowing this kind of lazy evaluation. > Arguably, this is very similar to the in_handler, but it eliminates the > function pointer and puts the responsibility in the proper layer. > > Or have I missed something? > > [snip] > >>>>> Show me the "lost work" by answering the above, and I will defend you. >>>>> If this is not forthcoming, then it is in our interest to continue on >>>>> the current path, despite any further objections. >>>>> >>>>> >>>>> >>>>> >>>> Hope this explains the background. >>>> >>>> >>> It does provide more context, but I do not think that it explains why >>> the implementation cannot be improved. The resistance to change in this >>> community worries me. The code is not in _any_ shape to be "preserved" >>> in its current state (unless we are talking about archiving backups). >>> OpenOCD needs to grow and evolve or it will not survive. >>> >>> If change is painful, then evolution is an outright killer. >>> >>> C'est la vie, >>> >>> Zach >>> >>> >>> >> I am tired of hearing this argument about resisting change. It is simply >> not true. I hear arguments about improving architecture, great but then >> there should be an new architectural plan at least for the affected >> parts. But changes done without understanding the code is not >> evolution. Big experiments should be done as experiments and then >> evaluated. >> > > I am just as tired of having to argue for change, but I have been > convinced that my argument here was flawed. You are correct in saying > that the size of these changes deserved a branch, but this admission > stems directly from hindsight. > > Breaking the trunk only causes problems because _everyone_ is using it > instead of regular releases. That is the maintainers fault to be sure; > this would not be a huge problem if everyone had their attention focused > on a release branch. This does not excuse rampant experimentation. > > In theory, the trunk _is_ an experimental branch to some extent. This > community's reliance on it helped show that Øyvind surpassed the de > facto limit to the community's tolerance for mainline breakage. > Arguably, this is not his problem alone. The community must shoulder > part of the blame for failing to make regular branches of the trunk for > the explicit purpose of maintaining stability... and for failing to > provide failsafe processes for handling experimental patches. > > > In this respect, I am starting to worry about the patches that I have > pending... are they too invasive? Should I post them first? If I have > to post every patch for others to consider, then why do I have commit > access to the repository (well, for my proposed rule above, to start). > Clear lines must be drawn, but these did not exist in any form. > > I know there are no policies because I asked _explicitly_ to see the > rules before agreeing to become a maintainer, initially declining while > waiting to see them. Despite my caution, I was assured that things were > kosher without written policies, but my instincts turned out correctly. > I mean, it could just as well have been me making a large commit that > angered the spirits down below. > > I tell ya': I would be on my way out the door if I had gotten the net > response that Øyvind received today, after only three weeks on the job > and given my initial reservations. During this all, I think he has > acted very professionally. I can see why Dick and Jeff left, and I am > feeling bad about the part that I played in it. Contributing to a > project without meaningful processes is too much like gambling. > > > At this point, I think we should treat it as water under the bridge and > move forward to ensure this kind of problem does not happen again. > A comedy of errors that will result in improved processes and a happy > ending for everyone. > > > Cheers, > > Zach > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
