[Mono-devel-list] (AMD64) Compiler Warnings (2)

[Willibald Krenn]

Miguel de Icaza schrieb:
> Hello,

Hi!
(Thanks for answering!)

> Before your patch can be considered to be included, it must meet the
> coding style for Mono (as pointed out by Duncan), otherwise you are
> adding more work for us to do.

Ok. Will add some spaces...

> People left for the weekend, so it is normal that you do not get a reply
> back, and the value of the patch does not have the sense of urgency
> since most of us are still using 32-bit machines.

This is perfectly ok, but maintaining a patch over weeks (current 
version is 4th iteration) is no interesting thing. Especially if it's 
kinda low-tech and cluttered over lots of files..
At last I would have appreciated some hint saying 'yes, chances are good 
for the patch to go into svn, but ...'. (=Positive feedback)

As of today I still don't know about the status of my patch, if some JIT 
hacker is working on a similar patch, if the new header file is ok, if I 
should rename the symbolic constants and/or the header, if the check for 
stdint.h in configure.in is ok, ....

I guess since this is my first patch I need a little guidance so it 
won't take forever until the patch is in a fashion that makes it 
svn-submittable.

> Different parts of Mono are maintained by different people, the best
> thing to do with your patch is to also file it on bugzilla, which is the
> standard location that we use to keep track of information.

Thanks for the hint! Did not know about this.. So if I file it there, it 
won't get lost in the dustbin of history? ;-)

> When a patch is really hot (because its so good, or it adds a lot of new
> functionality) people tend to be more responsive, but even in those
> cases, things might fall through the cracks.

Well, this patch fixes possible bugs on 64 bit platforms and does not 
change functionality (= is not likely to introduce new bugs) so I 
thought chances for approving it would be kinda high...

> Your patch must do something actually useful, consider all the patches
> that Ben has contributed to CVS.  They typically go through a series of
> postings to Bugzilla, they are reviewed time and again, and once we are
> happy with them, ChangeLogs are provided, regression tests are in place,
> they get commited.

Ok, so the preferred way is Bugzilla? (This is somewhat in contrast to 
the information presented on go-mono.com)
BTW: I consider bug fixes / compiler warning fixes to be useful.. (And 
thought of doing some more after this patch is in svn..)


> Also, you must be aware that for us to check your code into Mono SVN for
> the Mono runtime, we will need a signed letter from you that authorizes
> us to relicense the code. 

Yes, I know. However, I consider trivial patches like the current one to 
be public domain, so anyone can take them and do with them whatever 
he/she likes.. (I don't claim any Copyright for this nor do I need to be 
mentioned in Changelogs for stuff like this..)

As for 'cool new functionality', I'll sign your form - as long as I'm 
still allowed to use the code I submitted for my own purposes without 
having to ask Novell for permission.. IOW: I do not want to lose any 
rights on my code, but I accept to give the same rights I have to Novell.


>>Seems I'll go for (2), although I *strongly* would have preferred (1)..
> 
> 
> Query Bugzilla: you will see that there are plenty of patches pending
> and that go through a review process.

Ok, I'll do the following:
- Whenever I've completed/introduced some new -IMO interesting- parts 
(of the complete CO-Framework patch), I'll post them here, just in case 
someone wants to take a look and wants to comment on it. (But I don't 
expect anyone to take a look and/or add comments..)
- If I consider CO-Framework feature complete, I'll post a note here and 
file it on Bugzilla..
Be warend: Feature complete will mean lots of new files, hundrets of 
lines of code and hooks into mini c-code probably cluttered over the 
complete mini file..

In any case: I'll do the changelog after I have the ok for some 
rc-version of the patch to go in svn..

Thanks,
  Willi