On Dec 18, 2008, at 9:15 AM, [email protected] wrote:
On Thu, Dec 18, 2008 at 08:21:39AM -0800, Rick Altherr wrote:On Dec 18, 2008, at 8:16 AM, [email protected] wrote:I get your point. But if I were to just go and create tools/rlink_dtcas and tools/rlink_speed_table directories and nobody followed on, I'd look a bit silly. It works the way it is, and at such a time as a scheme such as you propose is enacted, it shouldn't be a huge deal to make the necessary modifications to the parts affected by my patch.Being the organizational neat freak that I am, I would prefer if you went ahead and put the rlink tools in trunk/tools. I'll locate any others that are already in the source base and move them. Having _something_ in trunk/tools will mean that future tools would have adefined location and we would request that the patch author place themthere.Ok. I will proceed thusly, as it appears such a scheme is being enactednow.It would be helpful, particularly to new people, to have a document that enumerates how things are laid out and how people are expected to do things. Particularly for situations such as mine where there are no existing examples, yet, from which to crib.Agreed. This should be done before our 1.0 release.When is that? I get the idea, alternately, that it is soon, and that itis undefined. Maybe both are correct.
The hope was to release 1.0 in a month or two. I'm trying to limit the number of new features that are being introduced into 1.0 to avoid moving the release out. I plan to bring the 1.0 branch in sync with trunk in the next few days and build a beta source tarball for people to test with.
-- 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
