Curious about the development cycle and community involvement

[R. Tyler Ballance]

Howdy, I'm a CPython developer by trade, but I've been watching
IronPython evolve and have recently started playing around with 2.6rc1
for a number of smaller projects [1][2].

While evaluating IronPython, I've run across a couple of issues [3] that
I think I'm capable of helping to fix but I notice that there's this
note in the FAQ regarding external contributions:

        Does the IronPython Team accept back source contributions into the IronPython and DLR codebases?

I'm curious as to whether this is still the case, FePy looks somewhat...
sleepy/out-of-date. How does the CodePlex Foundation fit into this? Does
it change things?

I know for some other projects (Mono comes to mind) they require an
MIT/X11 to commit to core and some paperwork with Novell (presumably so
they have their bases covered for commercializing the IP). Is this
something that might help open up IronPython to community contributions?


Furthermore, to the tune of the "development cycle" it's quite unclear
from the site how long the "release candidate" cycle is going to be
before the final version of 2.6.0 is released; how long are these cycles
typically?


I'm really excited about the prospects of incorporating IronPython 2.6
into more of my projects (particularly on top of Mono), but I'd like to
able to contribute back where I can to push the project forward.


Appreciate any feedback/thoughts :)


Cheers,
-R. Tyler Ballance

[1] http://github.com/rtyler/IronWatin
[2] http://unethicalblogger.com/posts/2009/10/crazysnake_ironpython_and_java_just_monkeying_around
[3] http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24533


_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[David DiCato]

Very cool - it's always fulfilling for us to see this level of enthusiasm from our users. Unfortunately, the legal barriers to our accepting external contributions are still very much there, as explained in the FAQ (http://ironpython.codeplex.com/Wiki/View.aspx?title=FAQ). As for the CodePlex Foundation, my (limited) understanding is that it could only help the situation, but the organization is brand-new, and we'll have to wait for it to become more established. If you'd like more specific legal information, I'd be happy to relay your questions to the right people.

In the meantime, simply reporting issues you're having with IronPython is one of the best ways to help us improve it. I saw the issue you referenced in [3], and I'm curious if you've run into any other problems through the course of your development. In general, we assign a higher priority to bugs that block a specific application, so you can still push the project forwards without actually writing the patches yourself.

Finally, regarding our dev cycle, I'll refer you to our IronPython 2.6 Roadmap (http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan) for our scheduling estimates. The only caveat here is that we are also doing a RC 2 release, which will push back the final release date accordingly.

- David

-----Original Message-----
From: users-bounces@... [mailto:users-bounces@...] On Behalf Of tyler@...
Sent: Monday, October 12, 2009 8:03 PM
To: users@...
Subject: [IronPython] Curious about the development cycle and community involvement

Howdy, I'm a CPython developer by trade, but I've been watching IronPython evolve and have recently started playing around with 2.6rc1 for a number of smaller projects [1][2].

While evaluating IronPython, I've run across a couple of issues [3] that I think I'm capable of helping to fix but I notice that there's this note in the FAQ regarding external contributions:

        Does the IronPython Team accept back source contributions into the IronPython and DLR codebases?

I'm curious as to whether this is still the case, FePy looks somewhat...
sleepy/out-of-date. How does the CodePlex Foundation fit into this? Does it change things?

I know for some other projects (Mono comes to mind) they require an
MIT/X11 to commit to core and some paperwork with Novell (presumably so they have their bases covered for commercializing the IP). Is this something that might help open up IronPython to community contributions?


Furthermore, to the tune of the "development cycle" it's quite unclear from the site how long the "release candidate" cycle is going to be before the final version of 2.6.0 is released; how long are these cycles typically?


I'm really excited about the prospects of incorporating IronPython 2.6 into more of my projects (particularly on top of Mono), but I'd like to able to contribute back where I can to push the project forward.


Appreciate any feedback/thoughts :)


Cheers,
-R. Tyler Ballance

[1] http://github.com/rtyler/IronWatin
[2] http://unethicalblogger.com/posts/2009/10/crazysnake_ironpython_and_java_just_monkeying_around
[3] http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24533

_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[R. Tyler Ballance]

On Tue, 13 Oct 2009, David DiCato wrote:

> Very cool - it's always fulfilling for us to see this level of enthusiasm from our users. Unfortunately, the legal barriers to our accepting external contributions are still very much there, as explained in the FAQ (http://ironpython.codeplex.com/Wiki/View.aspx?title=FAQ). As for the CodePlex Foundation, my (limited) understanding is that it could only help the situation, but the organization is brand-new, and we'll have to wait for it to become more established. If you'd like more specific legal information, I'd be happy to relay your questions to the right people.

Quite perplexing, I still don't understand the reasonings behind the
iron curtain (puntastic!) between the community of IronPython users and
the actual development of IronPython itself. I would be delighted if you
could pass my questions along to the relevant legality-folks with
regards to the CodePlex Foundation and the reasons behind the blockade
of external contributions.

I've signed legal disclosures to commit to other corporate backed
projects in the past, depending on the terms, I've not got too major of
an issue with it.

>
> In the meantime, simply reporting issues you're having with IronPython is one of the best ways to help us improve it. I saw the issue you referenced in [3], and I'm curious if you've run into any other problems through the course of your development. In general, we assign a higher priority to bugs that block a specific application, so you can still push the project forwards without actually writing the patches yourself.


For our specific usecase, our options for JSON are:
  1) Import and use System.Web.Script.Serialization.JavaScriptSerializer
    with the <T>.Deserialize
  2) Copy/paste the simplejson.py module into our tree

1 is kind of a non-starter since...I don't usually know what *type* the
JSON string I'm trying to deserialize
(JavaScriptSerializer.Deserialize() gives me a
System.Collections.Generic.Dictionary<T,T> in most cases, or a similarly
generic/non-python type)

2 is gross, as you might assume.


The project we're using IronPython previously (IronWatin, referenced
previously) is really new, so I've not started incorporating a lot from
the Python 2.6 standard library as of yet, so I can't comment on how
much of a "blocker" it is since we've only seen it with the "json"
module.

That said, if relative imports are borked, you don't really meet the
"2.6 compatibility" bullet on the roadmap ;)


> Finally, regarding our dev cycle, I'll refer you to our IronPython 2.6 Roadmap (http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan) for our scheduling estimates. The only caveat here is that we are also doing a RC 2 release, which will push back the final release date accordingly.

Thanks, this is helpful.


One last question, if I were to run a fork of the Subversion tree
(git-svn(1) woot) which branch should I be using? I see IronPython_Main
and IronPython_2_6 in trunk/ and I'm not sure which contains active
development.



Cheers

> -----Original Message-----
> From: users-bounces@... [mailto:users-bounces@...] On Behalf Of tyler@...
> Sent: Monday, October 12, 2009 8:03 PM
> To: users@...
> Subject: [IronPython] Curious about the development cycle and community involvement
>
> Howdy, I'm a CPython developer by trade, but I've been watching IronPython evolve and have recently started playing around with 2.6rc1 for a number of smaller projects [1][2].
>
> While evaluating IronPython, I've run across a couple of issues [3] that I think I'm capable of helping to fix but I notice that there's this note in the FAQ regarding external contributions:
>
> Does the IronPython Team accept back source contributions into the IronPython and DLR codebases?
>
> I'm curious as to whether this is still the case, FePy looks somewhat...
> sleepy/out-of-date. How does the CodePlex Foundation fit into this? Does it change things?
>
> I know for some other projects (Mono comes to mind) they require an
> MIT/X11 to commit to core and some paperwork with Novell (presumably so they have their bases covered for commercializing the IP). Is this something that might help open up IronPython to community contributions?
>
>
> Furthermore, to the tune of the "development cycle" it's quite unclear from the site how long the "release candidate" cycle is going to be before the final version of 2.6.0 is released; how long are these cycles typically?
>
>
> I'm really excited about the prospects of incorporating IronPython 2.6 into more of my projects (particularly on top of Mono), but I'd like to able to contribute back where I can to push the project forward.
>
>
> Appreciate any feedback/thoughts :)
>
>
> Cheers,
> -R. Tyler Ballance
>
> [1] http://github.com/rtyler/IronWatin
> [2] http://unethicalblogger.com/posts/2009/10/crazysnake_ironpython_and_java_just_monkeying_around
> [3] http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24533
>

_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Seo Sanghyeon-3]

2009/10/14  <tyler@...>:
> One last question, if I were to run a fork of the Subversion tree
> (git-svn(1) woot) which branch should I be using? I see IronPython_Main
> and IronPython_2_6 in trunk/ and I'm not sure which contains active
> development.

IronPython_Main does.

--
Seo Sanghyeon
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Michael Foord-5]

tyler@... wrote:

> On Tue, 13 Oct 2009, David DiCato wrote:
>
>  
>> Very cool - it's always fulfilling for us to see this level of enthusiasm from our users. Unfortunately, the legal barriers to our accepting external contributions are still very much there, as explained in the FAQ (http://ironpython.codeplex.com/Wiki/View.aspx?title=FAQ). As for the CodePlex Foundation, my (limited) understanding is that it could only help the situation, but the organization is brand-new, and we'll have to wait for it to become more established. If you'd like more specific legal information, I'd be happy to relay your questions to the right people.
>>    
>
> Quite perplexing, I still don't understand the reasonings behind the
> iron curtain (puntastic!) between the community of IronPython users and
> the actual development of IronPython itself. I would be delighted if you
> could pass my questions along to the relevant legality-folks with
> regards to the CodePlex Foundation and the reasons behind the blockade
> of external contributions.
>
> I've signed legal disclosures to commit to other corporate backed
> projects in the past, depending on the terms, I've not got too major of
> an issue with it.
>  

The IronPython team are well aware of the frustrating nature of the
restriction - and are just as frustrated as we are. The reason for the
restriction is that Microsoft has been sued in the past (and lost) for
shipping code written by third parties that they *thought* they owned
the rights to but didn't (they'd paid for the rights but the people
doing the selling didn't actually own the code - and of course Microsoft
are a much better target to sue than the people who sold the code).

In result any decision to ship third party code has to go through the
Microsoft legal department. Whilst this has been done for the IronRuby
project it has never happened for the (older) IronPython project. This
is something that the Codeplex Foundation *may* help with once it matures.

>  
>> In the meantime, simply reporting issues you're having with IronPython is one of the best ways to help us improve it. I saw the issue you referenced in [3], and I'm curious if you've run into any other problems through the course of your development. In general, we assign a higher priority to bugs that block a specific application, so you can still push the project forwards without actually writing the patches yourself.
>>    
>
>
> For our specific usecase, our options for JSON are:
>   1) Import and use System.Web.Script.Serialization.JavaScriptSerializer
>     with the <T>.Deserialize
>   2) Copy/paste the simplejson.py module into our tree
>
> 1 is kind of a non-starter since...I don't usually know what *type* the
> JSON string I'm trying to deserialize
> (JavaScriptSerializer.Deserialize() gives me a
> System.Collections.Generic.Dictionary<T,T> in most cases, or a similarly
> generic/non-python type)
>
> 2 is gross, as you might assume.
>
>  

Why is having a third party dependency 'gross'? It seems quite normal.

> The project we're using IronPython previously (IronWatin, referenced
> previously) is really new, so I've not started incorporating a lot from
> the Python 2.6 standard library as of yet, so I can't comment on how
> much of a "blocker" it is since we've only seen it with the "json"
> module.
>
> That said, if relative imports are borked, you don't really meet the
> "2.6 compatibility" bullet on the roadmap ;)
>  

That statement I would agree with...

All the best,

Michael

>
>  
>> Finally, regarding our dev cycle, I'll refer you to our IronPython 2.6 Roadmap (http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan) for our scheduling estimates. The only caveat here is that we are also doing a RC 2 release, which will push back the final release date accordingly.
>>    
>
> Thanks, this is helpful.
>
>
> One last question, if I were to run a fork of the Subversion tree
> (git-svn(1) woot) which branch should I be using? I see IronPython_Main
> and IronPython_2_6 in trunk/ and I'm not sure which contains active
> development.
>
>
>
> Cheers
>
>
>  
>> -----Original Message-----
>> From: users-bounces@... [mailto:users-bounces@...] On Behalf Of tyler@...
>> Sent: Monday, October 12, 2009 8:03 PM
>> To: users@...
>> Subject: [IronPython] Curious about the development cycle and community involvement
>>
>> Howdy, I'm a CPython developer by trade, but I've been watching IronPython evolve and have recently started playing around with 2.6rc1 for a number of smaller projects [1][2].
>>
>> While evaluating IronPython, I've run across a couple of issues [3] that I think I'm capable of helping to fix but I notice that there's this note in the FAQ regarding external contributions:
>>
>> Does the IronPython Team accept back source contributions into the IronPython and DLR codebases?
>>
>> I'm curious as to whether this is still the case, FePy looks somewhat...
>> sleepy/out-of-date. How does the CodePlex Foundation fit into this? Does it change things?
>>
>> I know for some other projects (Mono comes to mind) they require an
>> MIT/X11 to commit to core and some paperwork with Novell (presumably so they have their bases covered for commercializing the IP). Is this something that might help open up IronPython to community contributions?
>>
>>
>> Furthermore, to the tune of the "development cycle" it's quite unclear from the site how long the "release candidate" cycle is going to be before the final version of 2.6.0 is released; how long are these cycles typically?
>>
>>
>> I'm really excited about the prospects of incorporating IronPython 2.6 into more of my projects (particularly on top of Mono), but I'd like to able to contribute back where I can to push the project forward.
>>
>>
>> Appreciate any feedback/thoughts :)
>>
>>
>> Cheers,
>> -R. Tyler Ballance
>>
>> [1] http://github.com/rtyler/IronWatin
>> [2] http://unethicalblogger.com/posts/2009/10/crazysnake_ironpython_and_java_just_monkeying_around
>> [3] http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24533
>>
>>    
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users@...
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>    

--
http://www.ironpythoninaction.com/

_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Dino Viehland]

> That said, if relative imports are borked, you don't really meet the
> "2.6 compatibility" bullet on the roadmap ;)

This is a bug w/ relating to PEP 366 (Main module explicit relative
imports).  I've added a simple repro to the bug and will look at fixing
it for RC2.

That being said json isn't going to work w/ IronPython 2.6  The reason
is that the json module relies upon CPython's sre_* modules instead of
relying upon just the normal re module.  We'll presumably need to
re-implement all of json in order to make this work as we have no plans
to implement sre as it's been deprecated in favor of re which we already
implement.


_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[R. Tyler Ballance]

On Wed, 14 Oct 2009, Dino Viehland wrote:

> > That said, if relative imports are borked, you don't really meet the
> > "2.6 compatibility" bullet on the roadmap ;)
>
> This is a bug w/ relating to PEP 366 (Main module explicit relative
> imports).  I've added a simple repro to the bug and will look at fixing
> it for RC2.

Awesomepants.

> That being said json isn't going to work w/ IronPython 2.6  The reason
> is that the json module relies upon CPython's sre_* modules instead of
> relying upon just the normal re module.  We'll presumably need to
> re-implement all of json in order to make this work as we have no plans
> to implement sre as it's been deprecated in favor of re which we already
> implement.

Less than awesome. but a fair point. Do issues like this get logged back
to bugs.python.org? (IMHO that's a bug with Python, no reason to use
sre)

That said, is there a fairly straightforward means of bridging
collections like Dictionary<T,T> and List<T> to their python equivalent
types? If so, than wrapping
System.Web.Script.Serialization.JavaScriptSerializer would be a decent
enough workaround for now IMHO.


Thanks for the feedback, cj mention that you guys were good people ;)


Cheers,
-R. Tyler Ballance


_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Dino Viehland]

Tyler wrote:
> Less than awesome. but a fair point. Do issues like this get logged back to
> bugs.python.org? (IMHO that's a bug with Python, no reason to use
> sre)

It depends upon the issue.  In this case I haven't logged something yet as
I just realized this last week and haven't investigated it very thoroughly.
I've gone ahead and opened a bug (http://bugs.python.org/issue7130).  It
looks like Jython actually implements _sre so we'll see how this goes.

>
> That said, is there a fairly straightforward means of bridging collections
> like Dictionary<T,T> and List<T> to their python equivalent types? If so, than
> wrapping System.Web.Script.Serialization.JavaScriptSerializer would be a
> decent enough workaround for now IMHO.

Ok, after getting a fix for the relative imports it appears I have spoken too
soon.   Encoding to json works just fine w/ the json module, only decoding
doesn't work.  I guess that makes sense - you wouldn't use regexes for
encoding :)

So if you just need to encode you're good to go.

As far as a bridge we do already bridge our dictionaries and lists w/ normal
.NET dictionaries and lists in a variety of ways.  For starters they are
IDictionary/IDictionary<object, object> and IList/IList<object, object>.  
Also if we're calling a method which takes an IDictionary<K,V> or an
IList<T> we'll create a wrapper which converts the objects on the fly.
Apparently neither of those help with the JavaScript serializer though!

It does look like you can do:

dict(a.Deserialize[Dictionary[object, object]](a.Serialize(Dictionary[object, object]({"foo":42}))))

so you just need to convert the python objects to their .NET equivalents
on the way in and out which isn't too bad.

I don't think there's much else we can do directly other than asking the
team that owns that to support IDictionary and IList in addition to
the concrete types.

_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Count László de Almásy]

from the FAQ--
"there are a few key benefits to limiting IronPython checkins to
Microsoft employees. The most important being that some of our users
have stated that they would be unable to install IronPython if it
contained non-Microsoft intellectual property due to their employers'
policies. We'd like to enable as many people as possible to utilize
IronPython, and feel this is a bit more important than taking back
contributions"

i have to say, that's some of the oddest logic i've seen in quite a
long time. those few users with the restrictive employer policies must
be pretty important to outweigh the value of community code
contributions.

--
Cheers, László
_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[Vernon Cole-3]

There are many (otherwise intelligent seeming) managers with just such confused opinions about software.  Some managers at the company I worked for until recently did not trust any open source code "because it might be insecure."  Therefore, I was not supposed to use CPython, but IronPython was okay because it was a Microsoft product, and therefor secure.   For the same reason I was not supposed to use Linux. IMHO such idiots should be eternally condemned to use Visual Basic.
  The thing is, Microsoft's lawyers could find a way to adopt submitted software as their own intellectual property if they wanted to.   They could make a token payment to the submitter, for example, or have the submitter simply relinquish all rights to Microsoft.  Lawyers can do all sorts of weird things, which make no sense to ordinary mortals.  I am married to a lawyer and I still can't understand how she thinks. (Then again, I couldn't understand her before she got her law degree, either.)  One thing I have learned from her is that a good lawyer can take either side of any legal issue and make a convincing case of it.
  I think the only answer is to keep expressing the thought to management that the "no outside submission" policy makes the company look stupid. Then, someday, they will tell the lawyers to fix it, and it will get fixed.
--
Vernon Cole

On Thu, Oct 15, 2009 at 1:08 AM, Count László de Almásy <calmasy@...> wrote:

from the FAQ--
"there are a few key benefits to limiting IronPython checkins to
Microsoft employees. The most important being that some of our users
have stated that they would be unable to install IronPython if it
contained non-Microsoft intellectual property due to their employers'
policies. We'd like to enable as many people as possible to utilize
IronPython, and feel this is a bit more important than taking back
contributions"

i have to say, that's some of the oddest logic i've seen in quite a
long time. those few users with the restrictive employer policies must
be pretty important to outweigh the value of community code
contributions.

--
Cheers, László

_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
Users mailing list
Users@...
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com