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 <and...@aeracode.org> 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 <nateja...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com. >>>> To post to this group, send email to django-developers@googlegroups.com. >>>> 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 django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
