On Mon, 28 Apr 2008 12:41:02 -0600, Jim Deville <[EMAIL PROTECTED]>
wrote:
So, as the new guy on the other (MSFT) side of the fence,
Welcome, Jim! :D
I am interested in all of these suggestions and ideas.
Great!
In addition, I have some questions/suggestions for you.
* Would mirroring our internal repo on a commit-by-commit basis help
with the repository issues?
Depends on which issues you are referring to, though I can't imagine it
would hurt any of the issues, and will certainly help with many, if not
all of them.
Would it help with the ownership feelings?
Yes, especially if the external repository was seen as the master
repository with daily, hourly, or per-commit syncs with the internal MSFT
repository, not vice-versa.
* How can we be more transparent about what we are working on, and where
we are heading? A blog? A weekly posting?
This is always going to be somewhat of a gray area due to the fact that
there will always be things (e.g. new features un-related to the Ruby
language, related products such as development tools, DLR-specific
extensions, Silverlight, etc.) that the powers that be @ MSFT will not
want exposed to the outside community and/or given to the community to
control. These are both fair and understood concerns, but I believe easy
enough to work around. In this regard, if a line in the sand could be
drawn that stated something like,
* The community owns the Ruby implementation as it relates to the
external specs and existing Ruby applications.
* MSFT owns the rest.
And the community was then given control -- with John and associates
leading the way, of course -- of pushing forward the portion of the
repository they were in control of, I believe we would all be in the exact
position we've been jockeying for, that of controlling each of our
destinies and primary areas of drive and interest.
* Would mirroring the repo to other formats help? Would releasing alpha
binaries be worthwhile?
I think a per-check-in build process monitored and implemented by
something similar to CruiseControl.NET would be ideal. This would ensure
that the state of the repository at any given time was well understoood,
providing access to the resulting binaries with each new build for further
analysis and testing by anyone who felts so inclined to access the
binaries and begin running tests against them. In this regard, it would
be *great* to implement and Atom-based subscription service for keeping a
local cache of binaries up-to-date with the repository head. In fact,
I'll write that service if enough interest exists in having access to just
such a service.
I'm new, but I want to help build a community, and show that this is a
real OSS project. So, I really appreciate the discource. I think that
these meta discussions are worthwhile in helping define the community.
Agreed. Looking forward to see what you are able to make of all this!
And thanks!
--
/M:D
M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: [EMAIL PROTECTED] | [EMAIL PROTECTED]
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm |
http://www.oreillynet.com/pub/au/2354
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
