Could we agree to disagree and come together on improvements and clean-up?

[Thomas Xkey]

After x # of years of silence from me quietly reading the list and using gmp, I thought I'd toss my 2 cents into the fray.
 
Everyone is going to continue to disagree on licensing issues. [Prove me wrong?]
 
Most everyone in both 'camps' detests overly expensive software. So there is a strong dislike amongst some/most of Ma* and of Microsoft. Deal with that in your own way.
 
It appears highly likely there will be a fork. 
 
So, how about everyone try to come together on a redesign/cleaning-up of GMP/ GMP-X (aka MPIR)????  I myself avoid the internals in my 'middle' age - I prefer using Shoups NTL on top of gmp for most of my algorithmic stuff - I'm a simpleton that way :) (well that and an order of magnitude improvement in an algorithm trumps most constant factor speed ups of code *evil grin*)
 
There are a lot of build issues with GMP that need addressed - work together on that?
 
*Everyone* needs to stop being so stubborn. I took a multi-year break from code development to develop my toddler and you're approaching her in temper tantrums, negativity and stubbornness.
 
I have quite often *hated* the anti-MS position of many open source projects. It's better to have a wider audience for projects than a narrow one. I was an eager user of delta-trinitys & Brian Gs efforts. So how about gmp finally getting around to playing well with others? [I am not a big fan of MS, but I do appreciate Visual Studio and the continuous progress and evolution of software]
 
I have quite often disagreed with a lot of the gmp development process; since I decided just to use it rather than patch or work on modules I have kept silent. It does not mean I do not appreciate the present results and strength of the code. No project is easy. I am reminded of that 3 weeks a month as a single father!
 
So instead of barking disrespectful banter, how about being productive and finding the ground you can agree on and get down to turning out code?
 
1) Clean up the code base
2) Switch to a 'better' build system?  [i prefer CMake but Scons is growing on me. Boost.Build is porting to python for v2 but that is too far off in the future and I can't see it being better than Scons]
3) Both forks need a better process for code/patch submission along with improved visibility on change issues
 
4) Greater visibility on timelines & RAMs (roles and assignment matrices - such as whom is working or heading up work on a particular function, module, or tasks)
 
5) *cough* FORUMs instead of just dev-thread, discuss-thread -  you'll attract a larger pool of developers who may be interested in particular aspects with a larger # of categories.
 
something akin to www.mersenneforum.org - simple yet easy for someone after a long day of work to pop into whatever relevant discussion picques their interest
 
 
I'm going back to my factoring, elliptic curves, and hash function competition research - happy computing and make progress not ire :)
 
C++ya,
xkey - whose current project is sitting on her potty chair
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gmplib.org/list-archives/gmp-discuss/attachments/20080530/b0eb044c/attachment.html