While I share some of Andrew's concerns, I do think this is still a fairly good topic for GSoC.
However, I think the only way it could happen would be if Nate wants to mentor the project; Nate, can you mentor? If so, you should hook up with Andrew and make sure you apply to be a mentor so we can have you added before the review process. Jacob On Thu, May 2, 2013 at 4:11 AM, Andrew Godwin <[email protected]> wrote: > I feel like the deployment problem is one that cannot be solved in a mere 12 > weeks and I'm not sure django-deployer is the right approach to encourage > for this - it sits at the wrong level of abstraction and looks pretty > fragile, and I'd be hesitant to put any sort of official emphasis on it > without a lot of my qualms being answered. In particular, it appears to be > sitting at the lowest-common-denominator level of the various feature sets > and looks pretty immature. > > I'm not sure I could accept this without a much clearer idea of what's going > to happen and a very clear focus on what section of our user base it will > help. Deployment isn't something there can be a single solution (or even > pattern) for, and I think encouraging that could be a bad idea. > > Andrew > > > On Wed, May 1, 2013 at 8:20 PM, Nate Aune <[email protected]> wrote: >> >> Hi Russell and Florian, >> >> A bit late to the party, but hopefully there's still time for this GSoC >> proposal to be considered. I'm the maintainer of django-deployer. It was >> initiated at the DjangoCon 2012 sprint and recently revisited at the PyCon >> 2013 sprint. The overarching goal of django-deployer is to make it easier to >> get Django deployed. So far the focus has been on deploying to PaaS >> providers, because they require little to no sysadmin skills, and have the >> added benefit of being free for small projects. >> >> django-deployer is the sister project PaaS Cheatsheet, a larger >> documentation project that I've started recently. PaaS Cheatsheet is a guide >> for how to get a Django/Python deployed on various PaaS providers. >> >> The way django-deployer works is by asking a series of questions about >> your Django project, and then generates a generic deploy.yml file that >> captures all of your project's requirements. When you choose a particular >> PaaS provider, django-deployer then translates the requirements defined in >> the deploy.yml file and generates configuration files for that specific PaaS >> provider. >> >> I met Colin (a student in Taiwan) at the PyCon sprint, and he was >> responsible for single-handedly adding Google App Engine support to >> django-deployer. He brought considerable expertise to our sprint team, and >> shipped working code within a matter of hours. Since returning from PyCon, >> we've been working remotely together, and he has continued to be a dedicated >> contributor to the project. I have utmost confidence in his abilities to add >> even more cool features and improve code quality of the django-deployer tool >> if this project is accepted into GSoC. >> >> English is a second language for Colin, so he may have had some >> difficulties in defending his proposal, so please allow me to step in and >> clarify a few things. >> >>> >>> Firstly, I'm not familiar with Django-deploy; but from a quick inspection >>> of the project page it doesn't appear that anyone in the Django core team is >>> on the committee list. In order for you to have this proposal accepted as >>> part of the GSoC, you'll need to secure agreement from the project >>> maintainers of Django-deploy that they want the help your offering, that >>> your project proposal is sound, and that they're willing to commit to >>> applying any patches you produce. >> >> >> As stated above, I'm willing to work closely with Colin to meet the >> objectives described in the proposal. >> >>> Secondly, you haven't provided any timelines for your proposal. My >>> immediate reaction is that you're proposing a lot of work for a student to >>> complete in 12 weeks. For example, writing a fully tested and documented >>> database backend strikes me as a 12 week project in itself - yet this is >>> apparently just one line item in one part of your project proposal. >> >> >> I think you may have misread that part of proposal. He's not proposing to >> write a database backend. There is already one provided by the Google App >> Engine SDK, so we're simply incorporating that into the configuration >> scripts (i.e. adding a settings_appengine.py that substitutes the DATABASE >> setting value). >>> >>> >>> Lastly, your project proposal is very light on details. You're proposing >>> a lot of ideas, but you haven't really specified anything beyond "I'm going >>> to do it". Are there APIs that need to be specified? If, in the case of >>> something like a database backend, the APi is already specified, are there >>> going to be any complications in satisfying the API? We need a lot more >>> detail before we will be able to judge if you understand the project your >>> proposing, or if you are just proposing a bunch of ideas but haven't given >>> those ideas any more thought than "this sounds interesting" >> >> >> I think the draft proposal was intended to get initial feedback and was >> intentially light on details. Colin and I can work on specifying more >> details on the actual deliverables within the next couple of days. We've >> already posted some ideas for improving it to the Github issue tracker: >> https://github.com/natea/django-deployer/issues?state=open >> >> >You list "Refactor for Expandability" as last on your schedule. I think >> > it should be at the start, eg compare different solutions like GAE, heroku, >> > Gondor, find a >common subset and then write the backends accordingly. I >> > fear that if you do this the other way around you will have to throw away >> > most of the code for >heroku/GAE and rewrite it. >> >> That's essentially what we've started to do on the PaaS cheatsheet site. >> One interesting side benefit of looking at all the PaaS providers, is that >> we've able to identify the commonalities among them. >> >> >> >* Regarding storage stuff, you say "I chose Google Cloud Storage >> > according to the networking speed and authorization flow will be easier >> > than >> > using other >storage service such as S3.". Personally I don't think it's >> > wise to choose the easier storage (network speed should be no concern here >> > anyways), your API >should be able to allow to hook in the more complex >> > authorization flow too, what would be a better way to test your API than >> > using S3 :) >> >> I agree. It should be possible for the user to specify S3 as a storage for >> static assets. But I think Colin does have a point that if you're already >> going with Google App Engine, it makes sense to stick with other Google >> technologies for the storage of the assets. Obviously, if you're using >> Heroku you'd use S3 for that. >> >> >> >All in all this proposal imo tries to address way to much and focuses to >> > much on Google. It would be more useful to lay the groundwork for an API >> > instead. That >said, did you get in contact with the project authors about >> > mentorship (eg are they interested and do have the time for it), I am >> > pretty >> > sure none of the core devs >uses django-deployer, so mentoring it would be >> > a >> > bit suboptimal. >> >> I agree that Colin's draft proposal was too focused on Google, but I think >> that's simply because that is what he is most familiar with. As his mentor, >> I would guide him to adding support for the other providers (Heroku, >> OpenShift, Gondor, etc.) as we have already done for Dotcloud and Stackato. >> >> Judging from all the Django deployment talks at meetups around the >> country, it's fairly evident that deployment is and continues to be a hot >> topic, one that is often a stumbling block for people new to Django. I >> think Django would benefit greatly from tools such as django-deployer that >> minimize the friction, and give people an easy path to painless deployments. >> >> Nate >>> >>> >>> On Sunday, April 21, 2013, LittleQ@NCCU, Taiwan wrote: >>>> >>>> to django-developers: >>>> >>>> Sorry, I use Google Drive for proposing, and I original tend to >>>> copy&paste it to here but found it will get in a mess. >>>> >>>> so I put my proposal here: >>>> http://goo.gl/xJyJ9 >>>> >>>> My idea is to contribute to django-deployer and make some significant >>>> improvements for it. >>>> This proposal is still editing, but I pre-post it to prevent I'm >>>> thinking it in the wrong way. >>>> >>>> any questions or any advise are welcome, thank you, I'm really a big >>>> Django fan, and I hope I can make it better. >>>> >>>> cuz seems like there's no #django-dev, so feel free to add my XMPP >>>> directly. >>>> >>>> it's open for messaging anytime :D >>>> >>>> >>>> - Colin Su >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at >>>> http://groups.google.com/group/django-developers?hl=en. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
