Re: [myhdl-list] my patches

[Bob C. <Fl...@gm...>]

On 10/18/2011 02:51 AM, Sébastien Bourdeauducq wrote:
> On 10/18/2011 11:42 AM, Ben wrote:
>> So what now ?
> Well, since I disagree with your conservative policies, I will fork MyHDL.

That is certainly your prerogative, but I'd recommend against it.  Becoming part of a community can be difficult, but I believe both the process and the result are best for everyone.

The goal isn't personal glory or self-aggrandizement.  The goal is to evolve the product in a direction that benefits the entire community.

If you think MyHDL has conservative policies, you should try to get a Linux kernel patch accepted.  The MyHDL guidelines distill the wisdom of the engineering process in a manner that invites community participation.

I once tried to submit a Linux memory management patch, and by the time I was pushed and shoved through the community process, another programmer had created a patch that solved my specific problem much better than my original patch, while also solving other issues raised during the discussion.  Plus, his code was smaller, simpler, faster, and far better than mine.  It was a humbling experience, but it was also massively educational.  My main contribution wasn't my patch, but my description of the problem I was trying to solve.  Once the community agreed there was a problem, had fully fleshed it out, then agreed that it did need solving, the issue gained a life of its own.  I would have saved myself a lot of time, and gotten my problem solved sooner and better, if I had gone to the LKML before I had written a single line of code.

Plus, I doubt you really mean you are going to 'fork MyHDL'.  Are you going to create your own website to host and document your fork?  Are you going to port future changes to the MyHDL base over to your fork?  I doubt it: If you were willing to do that much work, you would have started it in this list.  What I think you mean to say is that you intend for your patch to never have more than a single user: You.  What a waste!

I'm very much a digital design and MyHDL newbie, and I was looking forward to the discussions that could have surrounded your patch, not starting with the patch (the patch is the END of the story, not the start).  I'm far from ready to look at your code: I would very much prefer to understand the problem you are trying to solve, to see why MyHDL can't handle it as-is, to learn from you, to see how you think, to see how the rest of the MyHDL community responds so I can learn more about how THEY think.

But when asked to start at the beginning, you instead choose to take your toy and run away from the playground.  Which is absolutely your right to do:  The code you wrote is your property, and you can do whatever you want with it.  But it leaves me feeling cheated of a great learning opportunity.

Please, take a deep breath, take a step back from your code, and try to start from the beginning:  What is the problem you are trying to solve?  Can you distill it to a small, clear example?  Can you help us see that a change to MyHDL (rather than a different design approach to the problem) is the best way to solve the issue?

Please?

-BobC