[Mono-devel-list] (AMD64) Compiler Warnings (2)
Willibald.Krenn at gmx.at
Mon Dec 6 09:05:31 EST 2004
Miguel de Icaza schrieb:
(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
> 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..
More information about the Mono-devel-list