Contributing?

mike-moscow · October 23, 2010, 6:30pm

mletterle@michael2:~/src/ironruby/Languages/Ruby/bin/Debug$ mono
ir64.exe
IronRuby 1.1.1.0 on 2.8.1 (master/e8a3aab Fri Oct 22 22:15:50 EDT 2010)
Copyright (c) Microsoft Corporation. All rights reserved.

print RUBY_PLATFORM
i386-linux>>>
[1,2,3,4].reverse.each{|x| print “Hello! #{x}”}
=> nil
Hello! 4Hello! 3Hello! 2Hello! 1=> [4, 3, 2, 1]>>>

Mono didn’t like how some stuff was done in Enumerable.cs, but a
slight refactoring (eliminate gotos, move an anonymous method out of a
method argument) did the trick. Working on running the tests now.

Changes are here: http://github.com/mletterle/ironruby/tree/linux

On Sat, Oct 23, 2010 at 7:02 AM, Michael L.
[email protected] wrote:

On Sat, Oct 23, 2010 at 3:19 AM, Tomas M.

To: [email protected]
Working on getting IronRuby.Console compiled now… already ran into a casing
issue >.<

contribute to Mono is the project/build system. When looking at it for

With a brave new world ahead for IronRuby, what do you all think
charge of both projects, can we move these into separate repos?
should live in its own repo, IMO. So should the Visual Studio tools.

http://rubyforge.org/mailman/listinfo/ironruby-core
Michael L.
IronRuby MVP
http://blog.prokrams.com

–
Michael L.
IronRuby MVP
http://blog.prokrams.com

mike-moscow · October 23, 2010, 7:00pm

I see. “DEBUG” seems to be redundant since it’s set by the default Debug
configuration in the project files.
Strange, I think I tried running IronRuby on Mono 2.8 and most of it
worked. If TryEnter implementation was missing something should have
failed. But this was compiled using our compiler not Mono’s. So maybe
the problem is just at build time?

We should work with JB to get any issues fixed.

Tomas

mike-moscow · October 23, 2010, 7:01pm

On Sat, Oct 23, 2010 at 5:44 AM, Mike M. [email protected] wrote:

On Oct 23, 2010, at 1:30 AM, Tomas M. <[email protected]
[email protected]> wrote:

I don’t understand how three distinct github repos that I need to map into
some directories on my disk whose relative location to each other is
hardcoded in some scripts in each are better than a single repo that has a
well-defined structure.

You are speaking like someone responsible for both languages and the DLR.

And you are speaking like someone who has tried hard several times to
contribute to IronRuby and failed because of a bloated project
structure.
I’m sure there are several people who would be willing to help you
figure
out what’s wrong. Where’s the repo with your contribution?

I’m making a suggestion as someone really only interested in IronRuby. The
repo isn’t called “DynamicLanguages”, it’s called “IronRuby”, which is at
best confusing. If only git had some way to define a link to another
repository as some sort of sub module…

Ah yes, and if only github had something like forking …

As a Rubyist I’d like to run a rake task to build to each defined target
and run the RubySpecs. It wouldn’t replace xbuild, just automate it. I don’t
understand the pushback to this idea.

If you want to create and maintain these, I’m sure no one would
complain. I
don’t understand the push back to the idea that the three core
contributors
were a little tired of building IronRuby and maintaining two build
approaches. I also don’t understand a Rubyist’s failure to see an
opportunity to contribute rake tasks to a project.

Why not make a dedicated repo for IronRuby free of the ancillary projects
and geared to someone like me? And likewise make the IronPython repo
friendly to our Pythonic friends?

IronPython already has a separate repo at
http://ironpython.codeplex.com/.

be any simpler.

Unfortunately I do see how this could be simpler.

Great! Fork the project and show everyone!

Sorry for the tone. If you were intending to come across differently, it
would help offer help and not critique the great work Tomas and the rest
have done. Try working on the project. Ask for help. You’ll receive it
readily. You may even find some people to help you restructure the
project.
If it works better, I’m sure you’ll get support for moving the project
to
that structure. Just don’t demand “your way right away” when you haven’t
contributed and don’t understand the history. It’s not your project yet.
Get
involved and make it yours.

Ryan R.

Email: [email protected]
LinkedIn: http://www.linkedin.com/in/ryanriley
Twitter: @panesofglass
Blog: http://wizardsofsmart.net/
Website: http://panesofglass.org/

mike-moscow · October 23, 2010, 7:27pm

Hey,

On Sat, Oct 23, 2010 at 6:01 PM, Michael L.
[email protected] wrote:

Mono didn’t like how some stuff was done in Enumerable.cs, but a
slight refactoring (eliminate gotos, move an anonymous method out of a
method argument) did the trick. Working on running the tests now.

When stumbling about cases like that, it would be really nice to
extract repros and file bugs for Mono.

Thanks!

mike-moscow · October 23, 2010, 8:17pm

Working on it actually… Maybe, possibly, with a patch as well…
(perhaps).

On Sat, Oct 23, 2010 at 12:34 PM, Jb Evain [email protected] wrote:

Thanks!

–
Jb Evain [email protected]

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

–
Michael L.
IronRuby MVP
http://blog.prokrams.com

mike-moscow · October 23, 2010, 10:33pm

I have to respecify DEBUG since I’m redefining the DefineConstants
property.

Running would have worked as long as you didn’t try to call that method

On Sat, Oct 23, 2010 at 12:29 PM, Tomas M.
[email protected] wrote:

To: [email protected]
On Sat, Oct 23, 2010 at 3:19 AM, Tomas M. [email protected]
wrote:

Sent: Friday, October 22, 2010 8:02 PM

On Fri, Oct 22, 2010 at 5:10 PM, Mike M. [email protected] wrote:

and I honestly don’t care about having to check IronPython. Now that
this, is it possible we can make this project reflect the realities of the
majority of folks that would like to contribute?

http://rubyforge.org/mailman/listinfo/ironruby-core
Ironruby-core mailing list

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

–
Michael L.
IronRuby MVP
http://blog.prokrams.com

mike-moscow · October 24, 2010, 1:31am

I don’t want a confrontation, I was just trying to voice some concerns I
have. If everyone is in agreement that the way things have been done is
the
best way they could have possibly been done, and that nothing should be
changed now that the project owners and the rules for making
contributions
are fundamentally different, then by all means continue.

On Sat, Oct 23, 2010 at 10:32 AM, Ryan R.
[email protected]wrote:

You are speaking like someone responsible for both languages and the DLR.

And you are speaking like someone who has tried hard several times to
contribute to IronRuby and failed because of a bloated project structure.
I’m sure there are several people who would be willing to help you figure
out what’s wrong. Where’s the repo with your contribution?

I don’t understand. Is this some sort of challenge?

I’m making a suggestion as someone really only interested in IronRuby. The

repo isn’t called “DynamicLanguages”, it’s called “IronRuby”, which is at
best confusing. If only git had some way to define a link to another
repository as some sort of sub module…

Ah yes, and if only github had something like forking …

I don’t think changing the structure in forked repos would do anyone any
good, as it would make sharing contributions between repos difficult.

I think you are confused to where I am puzzled about resistance. It is
not
about having rake tasks. I agree that they are easy enough to add and
maintain, and that whining about them would be quite ridiculous. That’s
not
my point, however. My point is that there would be more contributions if
it
were not a single monolithic repository. I also think most of the
historic
benefits of having a monolithic repo can be mitigated with submodules
and an
automated build and integration server.

Feel free to disagree.

Why not make a dedicated repo for IronRuby free of the ancillary
projects

and geared to someone like me? And likewise make the IronPython repo
friendly to our Pythonic friends?

IronPython already has a separate repo at http://ironpython.codeplex.com/
.

I dunno, it looks really, really similar to the IronRuby repo on GitHub
to
me. Is this synched with the GitHub repo? Is this where all the “Project
Merlin” changes are coming from?

mike-moscow · October 24, 2010, 2:17am

On Sat, Oct 23, 2010 at 4:09 PM, Mike M. [email protected] wrote:

You are speaking like someone responsible for both languages and the DLR.

And you are speaking like someone who has tried hard several times to
contribute to IronRuby and failed because of a bloated project structure.
I’m sure there are several people who would be willing to help you figure
out what’s wrong. Where’s the repo with your contribution?

I don’t understand. Is this some sort of challenge?

No, that’s just how I read your message. You seem to indicate that the
current repo structure causes difficulty when you want to contribute. If
you
need help finding your way around, I’m happy to help, as I’m sure are
many
others. (Of course, you may want the help of others as I’m a bit rusty
myself.)

I don’t think changing the structure in forked repos would do anyone any
good, as it would make sharing contributions between repos difficult.

True, but if you were able to create a repo structure you think would
allow
more freedom to contribute, then I think everyone would move to that
structure. Changing the structure is going to take work, and I think
most
people who have been contributing are fine with the current structure
since
they’ve been used to it for some time. Actually, several layers of the
repo
have already been removed, so it’s better than it was six months ago.

I think you are confused to where I am puzzled about resistance. It is
not

about having rake tasks. I agree that they are easy enough to add and
maintain, and that whining about them would be quite ridiculous. That’s not
my point, however. My point is that there would be more contributions if it
were not a single monolithic repository. I also think most of the historic
benefits of having a monolithic repo can be mitigated with submodules and an
automated build and integration server.

Feel free to disagree.

I don’t really disagree with you at all. I use that same strategy myself
on
my own projects. I just don’t want to volunteer to restructure the
entire
project, especially if people are actively working on integration
scenarios.
Yes, the project was originally in both TFS and git, so it had to play
nice
with both. Other options are now open. Hence why I suggested forking it
and
showing a better structure.

I dunno, it looks really, really similar to the IronRuby repo on GitHub
to

me. Is this synched with the GitHub repo? Is this where all the “Project
Merlin” changes are coming from?

I believe the sync is one-way, IronRuby includes IronPython. I’m sure
the
similarity in structure comes from the internal TFS repos that were used
and
the fact that the teams were both working on the DLR together. Someone
please correct me if this is wrong.

Cheers,
Ryan

mike-moscow · October 24, 2010, 5:22am

FWIW having separate IronRuby, IronPython, and Common repos that are
sub moduled(is that a word?) would make sense, that way changes that
are done in Common by both people working on Ruby and Python are
easily shared… the current configuration feels… fragile.

Perhaps the BEST thing to do is to layout what a more reasonable
structure could look like in concrete terms rather then just
complaining about the current setup.

The repo in general needs some love though, build instructions should
be in the README, and the current layout could use some explanations,
some files that seem to be needed are incorrect or in places different
than project files expect (specifically thinking of App.config here)

I think the fundamental problem is the current repo was never really
put together with the idea of someone coming in blind to it… the only
way to change that is to… well start changing it.

On the subject of the rake tasks, when the rake files were originally
there xbuild was nowhere near the state it is now, and it WAS a pain
to maintain, especially across platforms, we probably should have some
linux scripts to call xbuild though.

The most important thing, in my opinion, is that these discussions are
now occurring.

On Sat, Oct 23, 2010 at 7:09 PM, Mike M. [email protected] wrote:

And you are speaking like someone who has tried hard several times to

repository as some sort of sub module…

were not a single monolithic repository. I also think most of the historic

I dunno, it looks really, really similar to the IronRuby repo on GitHub to
me. Is this synched with the GitHub repo? Is this where all the “Project
Merlin” changes are coming from?

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

–
Michael L.
IronRuby MVP
http://blog.prokrams.com

mike-moscow · October 24, 2010, 1:48pm

I have to respecify DEBUG since I’m redefining the DefineConstants
property.

Running would have worked as long as you didn’t try to call that method

I would love to see your work. Ive been meaning to package ironruby
for
gentoo linux for ages, but so far have not got around to it. The main
reason
for this is that it doesn’t build “naked”. Gentoo has a policy of
staying as
close to upstream as possible combined with me being lazy and until a
couple
of days ago was unsure of whether I could contribute patches upstream.
none of
those made me particularly motivated to create patches

If you have made changes I would

like to get them merged into ironruby. so #if MONO’s would be nice
instead of a straight fix. (assuming they are acceptable)
like to get the issue fixed in mono (if its that doc one for which
there is
already a bug, but also that cast from dynamic to object one) so
please can
we file bugs upstream too.

On a more general note. if you are interested in ruby on gentoo I
suggest
you have a look at a fellow dev’s blog [1]. Its an interesting read
and you
won’t be disappointed Really please read it, you might learn some
of the
challenges gentooers currently face.

From a linux packaging perspective. Ultimately I would hope that we can
acheive nice, easy (for everyone), reproducable builds. Im perfectly
happy
with msbuild, but could we add bat/sh files that call msbuild/xbuild to
build
specific parts of the project. Could we document all the options
available to
configure the build (including defines if necessary, etc).

-Alistair.

[1] RubyNG – Flameeyes's Weblog
[2] 94374 – Eclass to support pre-compiling .net IL with mono

ps. Does ironruby have a irc channel, other place where dev’s hang
out?

mike-moscow · October 25, 2010, 11:11am

The project directory structure is a mess. Dozens of executable files in
the
versioning and what not.

mike-moscow · October 25, 2010, 1:55pm

On Sun, Oct 24, 2010 at 1:57 AM, Michael L. <
[email protected]> wrote:

FWIW having separate IronRuby, IronPython, and Common repos that are
sub moduled(is that a word?) would make sense, that way changes that
are done in Common by both people working on Ruby and Python are
easily shared… the current configuration feels… fragile.

There is a major problem: different vcs tools. I guess the IronPython
project will stay with TFS/SVN while IronRuby will use git(hub). Having
common submodule repos managed by different VCS would be a world of
pain.
There is no way of dividing the project into submodules if IronPython
doesn’t move to github/git. Maybe some git-svn magic would help and
mirror
versions on github of the svn repositories would be needed.

I think that another major problem the IronRuby project has are the 4
sites
with IronRuby content. There are like 4 sites now on github, rubyforge,
ironruby.net and the codeplex with different content on ironruby. This
is
madness, IronPython as only 2 sites, ironpython.net and codeplex and
that
makes sence. When I looked into the project I was just confused, because
I
couldn’t find any information and the little bits of Information were
scattered and outdated. And this is a real dilemma, because you just
can’t
move away from any of these sites: you have to stay at codeplex at
because
it is an Iron project, you have to stay at rubyforge because it is ruby
afterall, you can’t move from github, because all the ruby kids use git,
so
there is only ironruby.net left, but you can’t get rid of that either,
it’s
after all the ironruby domain.
The purposes of the sites need to be trimmed down: use codeplex and
rubyforge only for binary distribution, github for versioning, issue
tracking and wiki and ironruby.net as a presentation site just like
ironpython.net is, cut the documentation out of it and stuff it in the
github wiki, redudancy is hard to version.
I don’t think that keeping the issue tracking system on codeplex really
helps in any way: people who are interested only in IronRuby have to
register now on codeplex and github, people who are interested in bot
iron
projects will have to register on both anyway.

I guess splitting up this this project is a nasty nasty dilemma, because
the
project tries to unite different communities which have different tool
preferences.

mike-moscow · October 25, 2010, 8:05pm

On Mon, Oct 25, 2010 at 4:22 AM, Andrius Bentkus <
[email protected]> wrote:

There is a major problem: different vcs tools. I guess the IronPython
project will stay with TFS/SVN while IronRuby will use git(hub). Having
common submodule repos managed by different VCS would be a world of pain.
There is no way of dividing the project into submodules if IronPython
doesn’t move to github/git. Maybe some git-svn magic would help and mirror
versions on github of the svn repositories would be needed.

I don’t think this would be too difficult to work around. There is
already
some process that replicates changes from the IronPython’s CodePlex repo
to
IronRuby’s GitHub repo. If the current monolithic project structure were
broken up into submoldules, you could have just IronPython’s CodePlex
being
replicated to an IronPython git repo.

I think that another major problem the IronRuby project has are the 4
sites

it’s after all the ironruby domain.
The purposes of the sites need to be trimmed down: use codeplex and
rubyforge only for binary distribution, github for versioning, issue
tracking and wiki and ironruby.net as a presentation site just like
ironpython.net is, cut the documentation out of it and stuff it in the
github wiki, redudancy is hard to version.
I don’t think that keeping the issue tracking system on codeplex really
helps in any way: people who are interested only in IronRuby have to
register now on codeplex and github, people who are interested in bot iron
projects will have to register on both anyway.

I don’t see the number of content sites as a major problem. Rubyforge is
being phased out in favor of better tools, so I don’t think its a long
term
solution. (Even gem hosting has moved to rubygems.org instead of
gems.rubyforge.org.) I don’t think the ironruby.net site is holding the
project back at all, but I agree it could be better. I think a better
solution would be to replace it with a jekyll site running on GitHub.
Just
point the ironruby.net domain to GitHub and you’re done. The reason I
like
the jekyll approach is because it makes it much easier for folks to
create
and improve web content. Its just a pull request away from being
published.
I think that system works really well, and its free.

It doesn’t really matter where downloads are hosted, as long as
ironruby.netlinks to them. But they could just as easily be hosted on
GitHub.

The only thing that I’m aware is being used at CodePlex is the
ticketing.
Again, I think there are better ticketing solutions out there, most of
them
free for open source projects. I don’t really see a need for CodePlex
myself, but I understand the desire to stay on it for some things. Its
probable that you could also push the jekyll content to CodePlex (and
Rubyforge) if that was desired.

I guess splitting up this this project is a nasty nasty dilemma, because
the project tries to unite different communities which have different tool
preferences.

All the more reason to have separate repositories, IMO.

mike-moscow · October 25, 2010, 8:41pm

Can you be more specific? What’s wrong with the structure (other than
LCA_RESTRICTED directories, which I agree were there only to satisfy our
lawyers but can be now merged into other directories)?

Yes, there are executable files checked in. These are tools that are
needed for running scripts, tests and various code generators.

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Andrius
Bentkus
Sent: Monday, October 25, 2010 12:51 AM
To: [email protected]
Subject: Re: [Ironruby-core] Contributing?

The project directory structure is a mess. Dozens of executable files in
the versioning and what not.

mike-moscow · October 25, 2010, 8:42pm

As someone who attempted to dive into IronRuby a couple of months ago, I
found it difficult to discern the “IronRuby Story” from the various
websites.
By that I mean that was not immediately obvious to me what information
was
current and what was outdated. I’d like to see an executive summary of
the
project that is updated at least once a month and perhaps a
more conspicuous hub for FeRb activity. (For example, see the one page
site
we have for Caliburn → http://www.caliburnproject.com/)

I’m .NET dev, but a ruby beginner. However, we’re also a git shop,
OSS enthusiasts, and so on. That’s just to say that tooling and culture
were
not a roadblock.

I’d also be interested in contributing to the effort of web presence.

Christopher

mike-moscow · October 25, 2010, 8:43pm

My only comment on the sites:

github = source control,
rubyforge = mailing list,
codeplex = issue tracker/binary distro,
ironruby.net = documentaiton

1 and 2 are pretty set, I see no reason to change from them.

3 is probably fine as well, though having source control and issue
tracking in one location may be desirable.

Using gh-pages is an interesting idea, is ironruby.net being hosted
at Microsoft’s expense or one of the team members? That would
probably have some bearing on that. Regardless, I’d rather see a nice
README first.

On Mon, Oct 25, 2010 at 1:27 PM, Mike M. [email protected] wrote:

I don’t think this would be too difficult to work around. There is already
some process that replicates changes from the IronPython’s CodePlex repo to
IronRuby’s GitHub repo. If the current monolithic project structure were
broken up into submoldules, you could have just IronPython’s CodePlex being
replicated to an IronPython git repo.

This I agree with. The current repo structure is counter-intuitive
IMHO.

–
Michael L.
IronRuby MVP
http://blog.prokrams.com

mike-moscow · October 25, 2010, 9:37pm

On Mon, Oct 25, 2010 at 12:26 PM, Michael L. <
[email protected]> wrote:

Regardless, I’d rather see a nice README first.

+1

mike-moscow · October 25, 2010, 9:47pm

Yes, I agree our web sites need some work. Jimmy, what is that status of
the new design you started working on (the one IronPython.net has
already)?

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Christopher
Bennage
Sent: Monday, October 25, 2010 11:20 AM
To: [email protected]
Subject: Re: [Ironruby-core] Contributing?

As someone who attempted to dive into IronRuby a couple of months ago, I
found it difficult to discern the “IronRuby Story” from the various
websites.
By that I mean that was not immediately obvious to me what information
was current and what was outdated. I’d like to see an executive summary
of the project that is updated at least once a month and perhaps a more
conspicuous hub for FeRb activity. (For example, see the one page site
we have for Caliburn → http://www.caliburnproject.com/)

I’m .NET dev, but a ruby beginner. However, we’re also a git shop, OSS
enthusiasts, and so on. That’s just to say that tooling and culture were
not a roadblock.

I’d also be interested in contributing to the effort of web presence.

Christopher

mike-moscow · October 25, 2010, 9:56pm

Let’s assume IronPython moves to github.

There would be two options:

 We could just rename the current IronRuby repo to

“DynamicLanguages” repo and IronPython can use it as it is (more or
less).

 It might be possible to split the repo to 3 parts - IronRuby

specific, IronPython specific, and DLR, make a submodule for each and
combine those submodules into “DynamicLanguages” repo. So what’s exactly
the effective difference among the repo built this way and 1)? AFAICT
it’s only that super-module doesn’t track the head of the sub-module
automatically. You need to manually update it to the latest version. How
does that help us? If we have a (single) CI server that makes sure that
both IronPython’s and IronRuby’s heads are passing all tests, what is
the advantage of not using the latest source code of each other?

Or am I missing something (maybe I misunderstand what git submodule can
do)?

PS: All this is orthogonal to minor refactoring of the current directory
structure that is a no-brainer and I already mentioned them (like
removing LCA_RESTRICTED).

Tomas

From: [email protected]
[mailto:[email protected]] On Behalf Of Mike M.
Sent: Monday, October 25, 2010 10:28 AM
To: [email protected]
Subject: Re: [Ironruby-core] Contributing?

On Mon, Oct 25, 2010 at 4:22 AM, Andrius Bentkus
<[email protected]mailto:[email protected]>
wrote:

On Sun, Oct 24, 2010 at 1:57 AM, Michael L.
<[email protected]mailto:[email protected]> wrote:
FWIW having separate IronRuby, IronPython, and Common repos that are
sub moduled(is that a word?) would make sense, that way changes that
are done in Common by both people working on Ruby and Python are
easily shared… the current configuration feels… fragile.

There is a major problem: different vcs tools. I guess the IronPython
project will stay with TFS/SVN while IronRuby will use git(hub). Having
common submodule repos managed by different VCS would be a world of
pain. There is no way of dividing the project into submodules if
IronPython doesn’t move to github/git. Maybe some git-svn magic would
help and mirror versions on github of the svn repositories would be
needed.

I don’t think this would be too difficult to work around. There is
already some process that replicates changes from the IronPython’s
CodePlex repo to IronRuby’s GitHub repo. If the current monolithic
project structure were broken up into submoldules, you could have just
IronPython’s CodePlex being replicated to an IronPython git repo.

I think that another major problem the IronRuby project has are the 4
sites with IronRuby content. There are like 4 sites now on github,
rubyforge, ironruby.net http://ironruby.net and the codeplex with
different content on ironruby. This is madness, IronPython as only 2
sites, ironpython.net http://ironpython.net and codeplex and that
makes sence. When I looked into the project I was just confused, because
I couldn’t find any information and the little bits of Information were
scattered and outdated. And this is a real dilemma, because you just
can’t move away from any of these sites: you have to stay at codeplex at
because it is an Iron project, you have to stay at rubyforge because it
is ruby afterall, you can’t move from github, because all the ruby kids
use git, so there is only ironruby.net http://ironruby.net left, but
you can’t get rid of that either, it’s after all the ironruby domain.
The purposes of the sites need to be trimmed down: use codeplex and
rubyforge only for binary distribution, github for versioning, issue
tracking and wiki and ironruby.net http://ironruby.net as a
presentation site just like ironpython.net http://ironpython.net is,
cut the documentation out of it and stuff it in the github wiki,
redudancy is hard to version.
I don’t think that keeping the issue tracking system on codeplex really
helps in any way: people who are interested only in IronRuby have to
register now on codeplex and github, people who are interested in bot
iron projects will have to register on both anyway.

I don’t see the number of content sites as a major problem. Rubyforge is
being phased out in favor of better tools, so I don’t think its a long
term solution. (Even gem hosting has moved to
rubygems.org http://rubygems.org instead of
gems.rubyforge.org http://gems.rubyforge.org.) I don’t think the
ironruby.net http://ironruby.net site is holding the project back at
all, but I agree it could be better. I think a better solution would be
to replace it with a jekyll site running on GitHub. Just point the
ironruby.net http://ironruby.net domain to GitHub and you’re done. The
reason I like the jekyll approach is because it makes it much easier for
folks to create and improve web content. Its just a pull request away
from being published. I think that system works really well, and its
free.

It doesn’t really matter where downloads are hosted, as long as
ironruby.net http://ironruby.net links to them. But they could just as
easily be hosted on GitHub.

The only thing that I’m aware is being used at CodePlex is the
ticketing. Again, I think there are better ticketing solutions out
there, most of them free for open source projects. I don’t really see a
need for CodePlex myself, but I understand the desire to stay on it for
some things. Its probable that you could also push the jekyll content to
CodePlex (and Rubyforge) if that was desired.

I guess splitting up this this project is a nasty nasty dilemma, because
the project tries to unite different communities which have different
tool preferences.

All the more reason to have separate repositories, IMO.

mike-moscow · October 25, 2010, 10:52pm

Hey,

On Mon, Oct 25, 2010 at 8:19 PM, Tomas M.
[email protected] wrote:

 It might be possible to split the repo to 3 parts – IronRuby
specific, IronPython specific, and DLR, make a submodule for each and
combine those submodules into “DynamicLanguages” repo. So what’s exactly the
effective difference among the repo built this way and 1)?

The difference is that it then becomes easier for people that are only
interested in either IronPython or IronRuby to track commits. There
will be a timeline for each modules. And you get to follow the ones
you’re interested in. And if you’re only interested in one, your
timeline isn’t «polluted» with comments or commits from the others.

Jb