Contributing to MoreLINQ

21 views
Skip to first unread message

Leopold Bushkin

unread,
Jan 10, 2010, 11:37:54 AM1/10/10
to MoreLINQ Developers
I recently had a short email correspondence with Jon Skeet about
contributing to MoreLINQ.

I personally have found MoreLINQ to be quite useful, and I would be
interested in contributing to it, if possible. I've recently assembled
a library of my own extension methods for operating on sequences and
lists that I've found to be useful over the last couple of years. I
had considered releasing them as an independent library (either on
CodePlex or Google.Code) - but I think that they may be complementary
to the work that's happening with MoreLINQ.

I don't know what the road map is for MoreLINQ - what scope or vision
you have in mind for it - but if the team feels that any portion of
what I have is a good fit, I would be pleased to have it included in
MoreLINQ.

At the moment, I have about 27 extension methods that are
substantially different from those in both .NET 3.5, and MoreLINQ -
with a few more in the works that I haven't had a chance to convert
from their non-Linq versions yet. There's also a suite of
approximately 200 unit tests that exercise and validate the
implementation. The code is entirely my intellectual property and is
not affiliated with my employer or any other party - nor has any of
the code that I've included been a part of any other open source or
commercial product. Some of the code was developed for my other open
source project (Poker.Net) - but again that is entirely unaffiliated
with any other party.

I have a recent copy of the codebase available online at beanstalk -
which you can take a look at via anonymous subversion guest access at:
http://bushkingames.svn.beanstalkapp.com/lexigram. This is not an
official release, at the moment - just a version I'm providing to the
MoreLINQ team to decide if the code is a good fit. There's an
ExtensionMethods.txt that is part of the solution online - that
provides the signatures of the methods in the library and a short
synopsis of what each one does.

I have a version of the codebase that I have merged with MoreLINQ,
which I can also make available. I'm still in the process of getting
it converted to use some of the existing utility methods in MoreLINQ
(like ThrowIfNull), but it's pretty close.

Sincerely, L. Bushkin

I look forward to hearing from you.

Atif Aziz

unread,
Jan 13, 2010, 4:33:09 PM1/13/10
to moreli...@googlegroups.com
Hi,

I checked out some of the operators in your project and I think they would make a great addition to MoreLINQ. You have quite a few operators implemented and it's hard to review of all them. Why not take it a step at a time and add each operator as a separate commit into MoreLINQ rather doing a single big merge? You could create an issue for each operator you'd like to propose and implement them as patches or in branches, giving others an opportunity to review them individually.

- Atif

--
You received this message because you are subscribed to the Google Groups "MoreLINQ Developers" group.
To post to this group, send email to moreli...@googlegroups.com.
To unsubscribe from this group, send email to morelinq-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/morelinq-dev?hl=en.




Leopold Bushkin

unread,
Jan 13, 2010, 9:00:22 PM1/13/10
to MoreLINQ Developers
I would be happy to do that. I already have a local version of
MoreLINQ with my additional operators merged in. It would be easy to
incrementally commit them.

I don't think I have commit rights to the MoreLINQ project yet, but
once that were granted, I could create a branch, commit each operator
separately, and open an issue with a description of the change within
a couple of days.

On Jan 13, 4:33 pm, Atif Aziz <aziza...@gmail.com> wrote:
> Hi,
>
> I checked out some of the operators in your project and I think they would
> make a great addition to MoreLINQ. You have quite a few operators
> implemented and it's hard to review of all them. Why not take it a step at a
> time and add each operator as a separate commit into MoreLINQ rather doing a
> single big merge? You could create an issue for each operator you'd like to
> propose and implement them as patches or in branches, giving others an
> opportunity to review them individually.
>
> - Atif
>

> > morelinq-dev...@googlegroups.com<morelinq-dev%2Bunsu...@googlegroups.com>

Atif Aziz

unread,
Jan 14, 2010, 5:16:02 PM1/14/10
to moreli...@googlegroups.com
Hi Leopold,

You are now a project member. Welcome!

Best approach would be to create an issue per operator you plan to add along with a short description. Next, use the branch to add the operator and incorporate feedback from comments or reviews. Finally, if all goes well, the branch can be merged into the trunk. Let me know if anything is unclear or if you disagree with the approach.

Good luck,
- Atif

To unsubscribe from this group, send email to morelinq-dev...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages