[Mono-dev] questions regarding contributing

[Andy Waddell]

Ok, here's (hopefully) my first contribution.  I've attached the patch
to add a trivial 2.0 method on
System.Data.SqlClient.SqlParameterCollection.

--Andy Waddell


-----Original Message-----
From: Jonathan Pryor [mailto:jonpryor at vt.edu] 
Sent: Tuesday, September 20, 2005 4:12 AM
To: Andy Waddell
Cc: mono-devel-list
Subject: Re: [Mono-dev] questions regarding contributing

On Wed, 2005-09-14 at 10:30 -0700, Andy Waddell wrote:
> The first set of issues I ran into were pieces of the class library
> not yet in the Mono base, but in the Beta 2 version of .NET 2.0.  In
> each case I've either worked around it in our code by substituting
> from the 1.0 Framework or gone into my local copy of the Mono code and
> added what we needed.  I don't have write access to SVN, so my changes
> are local for now, but I'd be more that happy to contribute them (and
> our management is supportive of this).
<snip/>
> I've done 4 or 5 other little ones like this, but I'm not sure what
> the policy is regarding the .NET Framework version 2.0 stuff.  Given
> that the code in Beta 2 is subject to change, is there a hesitancy to
> apply all the stuff in Beta 2 to the Mono code base or is it just the
> case that nobody has gotten around to it?

It's just that nobody has gotten around to it.

Follow the coding guidelines listed at:

	http://mono.myrealbox.com/source/trunk/mcs/class/README

Place your code into an appropriate #if...#endif block.  For example, if
the new methods are part of .NET 2.0, place the methods into a #if
NET_2_0 block (or add them to an already existing NET_2_0 block).

Use `svn diff` to create a patch file, and email the patch file to
mono-devel-list.  We'll review the code and apply the patches, if
necessary.  If you do this often enough, miguel may give you an svn
commit account.  Even if you have a commit account, you shouldn't commit
your changes unless (1) you've gotten approval to commit the patch on
mono-devel-list first, or (2) you "own" the particular module you're
committing to.

> Is there a definitive place to check the status of what's done and
> what's not (other than the source code)?  

The source code is always the definitive place. :-)

There are tools to help.  In particular, the Class Status Page provides
a comparison of types/members between .NET and Mono.  See:

	http://mono.ximian.com/class-status

The one problem with the Class Status Page is that it can be out of
date, as it requires a manual update (and thus is out of date as soon as
the next CTP is released ;-).

 - Jon


-------------- next part --------------
A non-text attachment was scrubbed...
Name: descriptions.diff
Type: application/octet-stream
Size: 708 bytes
Desc: descriptions.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050920/c3ed31f3/attachment.obj