On Dec 18, 2008, at 9:06 AM, [email protected] wrote:
1) Spencer Oliver's concern about legal implications. If this is aproblem, nothing below matters. It is one vote (or not even a vote, so much as voicing of a possible concern, I can't say), but it only takes one vote to make something not unanimous. I don't know how such things workin this particular organization. The law appears to be on our side here, judging from what I and others have read, but none of us arelawyers. I would be extremely surprised if Raisonance were to be of anyhelp. They seem to be trapped in the '90s. There doesn't seem to be anything I can do to the patch that would address this. Is this going to stop the show or not?
I vote that we include rlink support. If Raisonance complains, we can remove it.
5) Keeping rlink_speed_table.c prebuilt is deemed fine, so no change needed there. There was discussion of having a separate area (eg: trunk/tools/{toolname}) for tools to do the prebuilding ("maintainer-mode" or "super-maintainer-mode"). What is not clear is how critical that is to acceptance of this patch. That may be cleared up in a reply to that email, though. It seemed like a good idea for the future,but it would affect a number of drivers, most of which I do not control or even necessarily understand. I could just unilaterally start putting stuff in tools/{toolname}, but that's going to be pretty goofy if nobodyelse does it. So is this a requirement or not? Therlink part of that could, of course, be changed when all the others are,later on, when such a thing gets instituted.
Your options for this patch are:
- Do not include the tools
- Put the tools in trunk/tools/{toolname}
I would prefer the latter, but the former is acceptable as long as a
the tools are included as a different patch at some point relatively
soon.
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
