Hi Tomaz, Thanks a lot for the detailed summary :-) Was really sad about being unable to attend this meetup (being on the other side of the globe).
Please see inline. On Wed, Jun 12, 2013 at 11:29 AM, Tomaz Muraus <[email protected]> wrote: > *Exception reporting for partial failures in the methods which result in > multiple API calls / HTTP requests* > Currently we have no standard interface for exceptions which get raised > during a partial failure in a method which has side affects. Partial > failure means that a function which performs multiple API calls failed half > way through and this potentially resulted in some (but not all) resources > getting created. > > We should provide a special exception for cases like this. This exception > should contain information about resources which got created. Users can > then use this information to perform "rollback" / cleanup partially created > resources. +1 to this feature - specially in cases of storage :-) - we can provide apis to sync folders with cloud storage. *Documentation* > > We are weak on the documentation side. > > Going forward we should strictly enforce that every patch which adds new > code / functionality contains documentation and appropriate docstrings. > Agree with that. I am one of the culprits in this crime :-) We could move the documentation along with the code (say under a docs directory). So any user who sends a patch will have to include the doc changes in the same pull request. This will ensure that doc changes are also part of the git/review workflow. Celery/Kombu projects do this and it is quite effective. *Migrating to git* > > We want to make contributing as easy as possible and SVN doesn't help with > that and increases barrier to entry. > > Action item here is me opening an Apache Infrastructure ticket for > switching to git. > Yaaay! Good news! Let me know if you need any help in this. Would this mean we will use Apache hosted git repo or can we move completely to github? I find github to be better for code reviews. > *Dropping support for Python 2.5* > > Supporting Python 2.5 adds code complexity which we would like to avoid. > Main problem is that a bunch of CLI tools based on Libcloud usually also > run on older versions of Linux (e.g. RHEL 5) which still ship with Python > 2.5. > This would be welcome. I would suggest that we do a small poll among the users to see if this would be an issue (before we make a change). Regards, Mahendra http://twitter.com/mahendra
