--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/06fcf0e3-b76f-4f3b-991d-0f163ce742b2%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
https://discuss.dgraph.io/t/switching-dgraph-to-a-liberal-license-dgraph-blog/2411/25?u=ahopkins
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/a39cdcf6-2a0e-43ae-8084-f0da71d0ce3d%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/d9e6d55f-615f-4118-848f-4e718b402101%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CAK_c-XJFz_9gYKfaDFta-8qj%2BKMgi82XV%3DHC%2Bc_0FqqF1WGN8Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMD2jVN--3-1%40amhopkins.com.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CAKkSmjiYv%3Diy43Lbz21En7eBWsc9%2Bo1%2BjFKpk4xDB_DwhzZwCQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BOf6C9WwW16_f7AWPUTQ0EabKt%3Dy%3DMxH3OMhCuzeM8o6g%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BOf6C9WwW16_f7AWPUTQ0EabKt%3Dy%3DMxH3OMhCuzeM8o6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BOf6C9WwW16_f7AWPUTQ0EabKt%3Dy%3DMxH3OMhCuzeM8o6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BOf6C9WwW16_f7AWPUTQ0EabKt%3Dy%3DMxH3OMhCuzeM8o6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/044444cb-7159-4028-8c28-c5fe8b457f21%40googlegroups.com.
Hey all, I am sorry it takes me so long to get back to these issues.I recently haven't had much time available so I've started transferring ownership. I've created a new org called "huge-success" and moved the project there. I gave ownership over the org to the current maintainers (Raphael and Eli) and Adam so far. I trust you all to carry Sanic into the future and do right by the maintainers and community.I tested a deploy to pypi and it looks like the encrypted credentials work. I'm not sure if I need to transfer ownership or what that would look like for a github org.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/5a2bb3a5-d3b2-4c96-8a81-f861b092a4c5%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMHBRWN--3-1%40amhopkins.com.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BOf6C9WwW16_f7AWPUTQ0EabKt%3Dy%3DMxH3OMhCuzeM8o6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/2971ac9a-73a1-44bc-96dd-4e1f682759f3%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BOf6C9WwW16_f7AWPUTQ0EabKt%3Dy%3DMxH3OMhCuzeM8o6g%40mail.gmail.com.For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/38a0de4c-d35b-47ee-848d-91f30ea74ec6%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/044444cb-7159-4028-8c28-c5fe8b457f21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMGsRKL--3-1%40amhopkins.com.
So I think the code of conduct that is already included is sufficient. It's precise without being overly specific and covers most of what we need.I think the bigger question is do we want to replace the contribution guide as a whole, or simply extend it? I think there's value in both paths, but it would be less disruptive to extend it than to replace it entirely. I feel like we need to clarify how to submit PRs and what needs to be included. Being very specific about PR naming would help us do things like automate changelog updates, but also requiring that any new additions be submitted with test fixtures and updated documentation would be important as well. Technical bits of contributing that aren't really touched on currently.Thoughts?-SOn Fri, Sep 14, 2018 at 11:02 AM Stephen Sadowski <stephen....@gmail.com> wrote:I'll take a look - submitted a PR for the updated changelog. Man is it a doozy!On Fri, Sep 14, 2018 at 2:28 AM Adam Hopkins <ad...@amhopkins.com> wrote:I just heard about this PEP that is all about how Python is reorganizing itself after the departure of Guido. While clearly we are not st the same scale, maybe there are some ideas in here we can adopt.--Adam HopkinsSep 14, 2018, 12:43 AM by stephen....@gmail.com:No, I've got it. I'm used to dealing with legal stuff from a professional standpoint, so it's not a big deal. I think the biggest issue will just be finding a model that will allow the greatest freedom of contribution while still being fair and reasonable on conduct side. I've seen some of the issues over the last 18 months where the code of conduct has been used against key contributors to projects, and I honestly don't care about race, nationality, sexuality, or creed of a contributor and don't want any of that to be in play at any point.-SOn Thu, Sep 13, 2018 at 4:36 PM Adam Hopkins <ad...@amhopkins.com> wrote:I hear you. I'm in the same boat. I am a little frustrated by the continued silence, but I guess that is what we have to deal with until we are fully accepted that this is the new strategy going forward.Do you want any help looking through any of that stuff? I am also a lawyer (jokes welcome), so I am used to ready through boring dull stuff.--Adam Hopkins14. Sep 2018 00:08 by stephen....@gmail.com:Yup, no worries. Not trying to make waves, just trying to help clean up some outstandings!On Thu, Sep 13, 2018 at 4:03 PM Adam Hopkins <ad...@amhopkins.com> wrote:Stephen: I am writing to you personally. As an FYI ... I am waiting to hear from some more people on the thoughts I laid out (Committee/Core, etc) before adding any teams to the sanic organization.--Adam Hopkins
1. The elephant in the room: what if Michael does not provide access to PyPI?
I’m very worried about that, we just got some half-measures so far…
2. Release cycle
I’m one of “these folks” that believe there’s a huge gap between a beta piece of software to a stable piece of software. Beta, for me, means that it works well; have a very strong and healthy community; code coverage is near 100% on almost every platform we can reach and the design of the code is mostly sustainable, with a lot of documentation. As for being production stable, the only difference is having feedback from those who uses it, for how long it uses and what their metrics says about the framework. Yes, I know, this can take a while. But that’s just for the development status, my two cents.
For the rest of the release proposal, I agree to use CalVer because we know there will be a lot of new (and fixed) things and that work might take a while. We can focus, from time to time, to solve most the issues, discuss and review PRs, adjust the documentation accordingly and use this as bases for LTS releases. LTS releases don’t quite requires a fixed release cycle, but mostly observe code quality, issues growth and PRs submitted. One of the main reasons I propose this is the evolution of dependencies and also Python versions; let’s take for example the websockets or multidict: some of their upgrades have broke Sanic here and there.
(item 2) Each release has a designated release manager (it could be the same person each time).
Agreed.
3. Features and enhancements
I guess 50% + 1 is the fairest model (excluding the author, for biasing reasons), and if a minerva vote is required, that shall be given to the author if a PR is also provided under our code of conduct. I just don’t know if these discussion can occur on github (open to everyone) or in the group and what to do if some member is unable to vote for any reason (due date?). I mean “discussion” because we need to provide a constructive feedback instead of “yes” or “no”, not only for us but to encourage others to do the same without the “fear” of being bashed over an idea that might sound stupid for one or other individual (we’re humans after all).
4. Repositories
(item 4) What repositories should the organization control? Should any of the existing features be removed to a separate package (ex. testing)?
I think this might be a good idea, since I’ve seen some users complaining about having aiohttp
as a dependency just because of the test client. Perhaps websockets support can be separate as well, so we can mitigate any problems regarding the websockets dependency in a different project without the need to touch Sanic itself at all.
(item 4) It has been suggested that an organization might also adopt some of the more popular third-party packages (https://github.com/channelcat/sanic/issues/1245#issuecomment-415159651).
That might help other developers to have a better visibility of the Sanic ecossystem, although I feel a little dubious about it because these packages will need maintainance the same way as Sanic; why? Just check out how many forks of sanic-openapi
are out there. Even I made one in my early days with Sanic ;-D
This also opens a door for optimizations, C, Cython, you name it. We already depend on binary libraries anyway (httptools
does not provide a pure Python version AFAIK).
(item 4) I would like to see its requirement pulled out separately as an option: pip install sanic[websockets]
That would be a great idea as well!
5. Style Guide
black
, oh yes! Let’s stick to 79 lines (as PEP8 requires) and just use black
for consistency. The code remains readable and should pass in any other linters. Of course, there are some ideas and models for other tools like isort
, but this debate can be left for another time.
6. Standards
(item 6) There used to be some benchmark standards. I am not sure what happened to them. Anyone want to work on creating a new set? Since one of the features and draws of the framework is its relative speed, I suggest we adopt a benchmark standard that commits need to pass before being adopted.
This is nice, though debatable: a new feature may be awesome, but can slow down Sanic by 3% overall (naive example). How do we handle these trade-offs?
(item 6) Same thing for testing. We can do better than the current 83%.
Hell yeah. At least 95% should be testable.
7. Next steps/first release
(item 7) What would a first community backed release look like? I would suggest that we tackle any low hanging fruit, and not any major changes. The main goals for a first release being increased testing and code coverage, documentation, and stability. Once we have an LTS in place, then we start planning the features for the 19.03 release.
Agreed as well.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMoFtSN--3-1%40amhopkins.com.
Ok, here I go with my comments ...1. The elephant in the room: what if Michael does not provide access to PyPI?
I’m very worried about that, we just got some half-measures so far…
2. Release cycle
I’m one of “these folks” that believe there’s a huge gap between a beta piece of software to a stable piece of software. Beta, for me, means that it works well; have a very strong and healthy community; code coverage is near 100% on almost every platform we can reach and the design of the code is mostly sustainable, with a lot of documentation. As for being production stable, the only difference is having feedback from those who uses it, for how long it uses and what their metrics says about the framework. Yes, I know, this can take a while. But that’s just for the development status, my two cents.
For the rest of the release proposal, I agree to use CalVer because we know there will be a lot of new (and fixed) things and that work might take a while. We can focus, from time to time, to solve most the issues, discuss and review PRs, adjust the documentation accordingly and use this as bases for LTS releases. LTS releases don’t quite requires a fixed release cycle, but mostly observe code quality, issues growth and PRs submitted. One of the main reasons I propose this is the evolution of dependencies and also Python versions; let’s take for example the websockets or multidict: some of their upgrades have broke Sanic here and there.
(item 2) Each release has a designated release manager (it could be the same person each time).
Agreed.
3. Features and enhancements
I guess 50% + 1 is the fairest model (excluding the author, for biasing reasons), and if a minerva vote is required, that shall be given to the author if a PR is also provided under our code of conduct. I just don’t know if these discussion can occur on github (open to everyone) or in the group and what to do if some member is unable to vote for any reason (due date?). I mean “discussion” because we need to provide a constructive feedback instead of “yes” or “no”, not only for us but to encourage others to do the same without the “fear” of being bashed over an idea that might sound stupid for one or other individual (we’re humans after all).
4. Repositories
(item 4) What repositories should the organization control? Should any of the existing features be removed to a separate package (ex. testing)?
I think this might be a good idea, since I’ve seen some users complaining about having
aiohttp
as a dependency just because of the test client. Perhaps websockets support can be separate as well, so we can mitigate any problems regarding the websockets dependency in a different project without the need to touch Sanic itself at all.
(item 4) It has been suggested that an organization might also adopt some of the more popular third-party packages (https://github.com/channelcat/sanic/issues/1245#issuecomment-415159651).
That might help other developers to have a better visibility of the Sanic ecossystem, although I feel a little dubious about it because these packages will need maintainance the same way as Sanic; why? Just check out how many forks of
sanic-openapi
are out there. Even I made one in my early days with Sanic ;-DThis also opens a door for optimizations, C, Cython, you name it. We already depend on binary libraries anyway (
httptools
does not provide a pure Python version AFAIK).(item 4) I would like to see its requirement pulled out separately as an option: pip install sanic[websockets]
That would be a great idea as well!
5. Style Guide
black
, oh yes! Let’s stick to 79 lines (as PEP8 requires) and just useblack
for consistency. The code remains readable and should pass in any other linters. Of course, there are some ideas and models for other tools likeisort
, but this debate can be left for another time.
6. Standards
(item 6) There used to be some benchmark standards. I am not sure what happened to them. Anyone want to work on creating a new set? Since one of the features and draws of the framework is its relative speed, I suggest we adopt a benchmark standard that commits need to pass before being adopted.This is nice, though debatable: a new feature may be awesome, but can slow down Sanic by 3% overall (naive example). How do we handle these trade-offs?
(item 6) Same thing for testing. We can do better than the current 83%.
Hell yeah. At least 95% should be testable.
7. Next steps/first release
(item 7) What would a first community backed release look like? I would suggest that we tackle any low hanging fruit, and not any major changes. The main goals for a first release being increased testing and code coverage, documentation, and stability. Once we have an LTS in place, then we start planning the features for the 19.03 release.
Agreed as well.
Hey Folks,Happy to see sanic start gaining some momentum again, would love to be involved in some way.2. One thing I would mention when it comes to assigning a "production" label to sanic is that 8.1 was the first release of sanic that would even pip install on windows. Qualitatively it seems like windows is a secondary concern for most sanic development and I'm not necessarily suggesting we make it an officially supported deploy platform but we should at least have a discussion about what guarantees we make there (if any).3. My guess is most things won't need to come down to a vote and I don't think we should make them if they don't have to. So far it seems the biggest obstacle to getting PR's merged has just been getting them reviewed. That said if something does become contentious totally fine with majority rules4. I think before another repository gets on boarded it should have a champion / lead, there are definitely some things that make sense as sanic adjacent repos but we have to commit to maintaining them if we onboard responsibilities.5. strong proponent of pep8, mildly displeased with how ugly black tends to be but if it makes life easier than so be it.6. I think a benchmark suite would be an awesome idea7. +1
--
You received this message because you are subscribed to a topic in the Google Groups "Sanic Task Force" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sanic-dev/WXbBxNo7Zek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/b2a6230e-7996-4489-9c68-1fd170dd660f%40googlegroups.com.
Stephen, Alec, all,Re-reading what I wrote regarding item 3, I think I owe you all an apology because I was not able to correctly put my idea into words. I'll try to break them down:For voting: I'm thinking way ahead of time, when the time comes to insert new features into Sanic. Of course, not all new features would have to go through this bureaucracy I mentioned if is a simple feature or something that would bring nothing but benefits, but for more sensible things, let's say, a new feature that might break backward compatibility, I think that the "voting" will be almost natural.For minerva voting: I gave the idea to leave an eventual minerva vote for the author with a PR to be more like an encouraging variable to other developers to bring new features to Sanic - instead of just opening an issue saying "I want support for Jinja templates", and that's it ;-)
My best regards,Richard.
On Thu, Sep 20, 2018 at 12:43 PM alec buckenheimer <abucke...@gmail.com> wrote:
Hey Folks,Happy to see sanic start gaining some momentum again, would love to be involved in some way.2. One thing I would mention when it comes to assigning a "production" label to sanic is that 8.1 was the first release of sanic that would even pip install on windows. Qualitatively it seems like windows is a secondary concern for most sanic development and I'm not necessarily suggesting we make it an officially supported deploy platform but we should at least have a discussion about what guarantees we make there (if any).3. My guess is most things won't need to come down to a vote and I don't think we should make them if they don't have to. So far it seems the biggest obstacle to getting PR's merged has just been getting them reviewed. That said if something does become contentious totally fine with majority rules4. I think before another repository gets on boarded it should have a champion / lead, there are definitely some things that make sense as sanic adjacent repos but we have to commit to maintaining them if we onboard responsibilities.5. strong proponent of pep8, mildly displeased with how ugly black tends to be but if it makes life easier than so be it.6. I think a benchmark suite would be an awesome idea7. +1
--
You received this message because you are subscribed to a topic in the Google Groups "Sanic Task Force" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sanic-dev/WXbBxNo7Zek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/b2a6230e-7996-4489-9c68-1fd170dd660f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWnvmUZqHPcVLWor4FGzXMLEvHkdmnrpRpKvQBWzEa1jMQ%40mail.gmail.com.
I’ve read Adam’s recap yesterday and went to bed thinking about some of these stuff.
I think I’ll take the liberty of making a proposal that I believe it can bring more stability to the codebase as well unleash some of the developers to take on what they believe is their strengths:
pytest-sanic
under the huge-success
umbrella to relieve the Sanic package of having aiohttp
as dependency.This might sound like “extra work” or “not what we initially agreed”, but I think it will be the shortest way to bring the stability we target for Sanic. Furthermore, the timing for doing this is better before the first LTS version than after (to introduce "breaking changes").
That’s just my two cents, more like a personal hint. By no means this should be seen as me trying to “put the wagon in front of the horses” (I don’t even know if this expression exists in English, hahaha), I already accept that the current plan is better for everyone (and way better than no plan at all).
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LMsky0c--3-1%40amhopkins.com.
I think at this point I’d like to hear any dissent from the group about Adam’s writeup. I’m mostly interested in as-of-yet unvoiced concerns, mostly because I’d like to get them addressed before we start endeavoring to make the changes rather than have them crop up later. I always want us to be willing to hear out the devs, users, and PR authors but I want to kick off the next phase of Sanic with everyone being on relatively the same page.
Me too. C’mon people, we are looking forward for your voice on any matter that comes to mind 😉
Now that I'm thinking about it we should probably decide on and announce a formal sanic communication channel. The only reference to this forum is via a now closed github issue. I'm fine with google groups being that channel (even though I keep getting mail undelivered errors) but unless there is something we need to discuss that we'd prefer a smaller group for I think it makes sense to memorialize the outcome of the "next steps" discussion in whatever channel we decide on. I'd suggest proposing a simple PR against the README.md with a link to whatever we decide on. Then we can accept the "next steps" proposal unless there are further objections.personally +1 for discourse, think it works well for the rust community. I know there is a gitter but I'm not sure what the status is on the ownership of that.
--
You received this message because you are subscribed to a topic in the Google Groups "Sanic Task Force" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sanic-dev/WXbBxNo7Zek/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWmT3EYsBgB-6yvm4wt%2BMW_1ROe__2pboHfAr2W0OZn0jQ%40mail.gmail.com.
Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CADcSD%2BN81dK8n1sjSs6NGkFxM%2B9D024psJrXAwOY19feJvwZ8w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/DM2PR0801MB1007AD5AF62C6F987E8F9162AD110%40DM2PR0801MB1007.namprd08.prod.outlook.com.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/5ad0fdd1-9d63-4ba6-9c80-2b8c8365ec22%40googlegroups.com.
Wow, this is some great stuff. I'm still internalizing some of your points, but wanted to say thanks for the input.As a father of 4 soon to be 5, I totally understand the "catch up" time. Regards for your family.--Adam Hopkins
Sep 22, 2018, 9:45 PM by aymeric.augustin@polytechnique.org:
Hello,Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.Based on my experience with governance of open-source projects, my general advice would be:- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):1. You'll get it eventually. If you really don't, switch to something like sanic-ng.2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.3. Prefer consensus.4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)5. Black is good.6. I don't know.7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.Best regards,--Aymeric.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
I like Aymeric's insight - as few of us have been actively involved in larger open source projects, hearing about how django is doing it is helpful.On the other hand, sanic isn't nearly the size nor has the contribution level as django, and I have to wonder if we just embed it in our code that we should periodically - perhaps every LTS release? - review our modus operandi as well as any time a contributor brings a concern to the table about how we are operating.I can see that if we had tens upon tens of contributors, even hundreds, a core team acting as gatekeepers might slow things down. I can certainly see how that would prevent those on said 'core team' from contributing in the way they best can.For now - I'd like to see us pick a direction and go it. In that vein, I'd like to strongly push for the following places to start:- CalVer 18.12 LTS (beta) with a goal of 19.12 LTS being a stable release, if not sooner. I like the idea of quarterly minimum releases. It'll keep us from the 9 month gap again at minimum.- I think the release manager should handle releases for a year starting with the LTS, giving that person the responsibility for handling security and other changes to the LTS until the next one is released.- Consensus decrees for added features or breaking changes to existing features; I will concede the miranda vote to the PR author which I think eliminates me as the sole dissenter for that- use black as rigorous, opinionated style enforcement- freeze everything but bug fixes and additional test coverage on 10/1 for 18.12 LTS- If no one else will volunteer as the RM for 18.12 LTS, I'll do it.Thanks,
-SOn Saturday, September 22, 2018 at 11:27:35 PM UTC-5, Adam Hopkins wrote:
Wow, this is some great stuff. I'm still internalizing some of your points, but wanted to say thanks for the input.As a father of 4 soon to be 5, I totally understand the "catch up" time. Regards for your family.--Adam Hopkins
Sep 22, 2018, 9:45 PM by aymeric....@polytechnique.org:
Hello,Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.Based on my experience with governance of open-source projects, my general advice would be:- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):1. You'll get it eventually. If you really don't, switch to something like sanic-ng.2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.3. Prefer consensus.4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)5. Black is good.6. I don't know.7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.Best regards,--Aymeric.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/5ad0fdd1-9d63-4ba6-9c80-2b8c8365ec22%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/c0194464-ad26-42ae-833c-38fa780c2150%40googlegroups.com.
Sep 22, 2018, 9:45 PM by aymeric.augustin@polytechnique.org:
Hello,Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.Based on my experience with governance of open-source projects, my general advice would be:- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):1. You'll get it eventually. If you really don't, switch to something like sanic-ng.2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.3. Prefer consensus.4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)5. Black is good.6. I don't know.7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.Best regards,--Aymeric.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/5ad0fdd1-9d63-4ba6-9c80-2b8c8365ec22%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+unsubscribe@googlegroups.com.
Sep 22, 2018, 9:45 PM by aymeric....@polytechnique.org:
Hello,Le jeudi 13 septembre 2018 09:42:42 UTC+2, Adam Hopkins a écrit :Aymeric: I know you've been silent so far. I think it is great that you are a fly on the wall right now. With your background and experience, do you have any thoughts to share on do's and don'ts when organizing a project like this?To be honest I'm catching up with the conversation only today. Having a one-month old toddler leaves little time for working on open-source.I'm confident that things will work out fine — with a caveat for the ideas currently floating around voting; I'll explain below.Based on my experience with governance of open-source projects, my general advice would be:- Trust people. Be welcoming. Don't overthink governance. Don't create overlords. Adopt a Code of Conduct and follow common sense rules like "assume good faith", "build consensus around what you're doing", and "don't merge your own patches". Give commit access liberally. Prefer "contributor" to "core dev". (If you're curious why, you can read on dsf-members why we're about to dismantle the Django core team.)- Ensure all functions are staffed appropriately: writing code is the obvious one, but writing documentation, triaging tickets, managing the release schedule, etc. are instrumental to the success of the project. If there aren't enough volunteers for some of these functions, keep in mind it's an issue and try to onboard new contributors. Make sure the bus factor is kept high especially for GitHub, PyPI, ReadTheDocs, etc. access permissions.- Consensus beats voting in volunteer teams. Not only do votes create frustration for the losing side, but votes on mailing lists happen under social dynamics that remove many benefits. Not having a secret ballot makes it hard to say no once three respected people have said yes. It's easier to express dissent when it's expected that a discussion will lead to consensus. Voting may be used as a last recourse solution. In that case I would recommend a strong majority, for example 4/5th of cast votes. If there's no consensus, then the status quo wins. If 4/5th feels too conservative, go for 3/5th. This calibrates expectations for the project: everyone knows you need this fraction of the team to agree with you to go ahead. I think that 50% + 1 isn't enough.Regarding your list of questions, here are very short answers (in the spirit of "strong opinions held weakly"):1. You'll get it eventually. If you really don't, switch to something like sanic-ng.2. Use whatever looks nice to you. It won't affect the success of the project. The drawbacks of bikeshedding this decision may outweigh the benefits of a change.3. Prefer consensus.4. Once you have an organization that's easy to join, adopting plugin repos makes sense. Trac does this; I transferred a plugin to their org and others are maintaining it now :-)5. Black is good.6. I don't know.7. Yes, clean up the bug tracker and release whatever's ready as soon as you're confident that there aren't too many regressions (or that you can fix them quickly.)At some point I may have time for open-source again, rewrite websockets to provide a sans-I/O layer, and get in touch to plug that into sanic or sanic-websockets. I'm also keeping an eye on unvicorn which has fairly similar goals and scope.Best regards,--Aymeric.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/5ad0fdd1-9d63-4ba6-9c80-2b8c8365ec22%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
--You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/c0194464-ad26-42ae-833c-38fa780c2150%40googlegroups.com.For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Sanic Task Force" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sanic-dev+...@googlegroups.com.
To post to this group, send email to sani...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/6c565be8-adb0-48a4-a21f-3e52660b3071%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWk65P6PJWvA4njE2s2Dm6H_XJVvPc5wh%2BB6JNOhE_8fhw%40mail.gmail.com.
Stephen, yes, I registered the domain for us. We are looking into discourse and Digital Ocean as Adam mentioned and I think he's working on an idea of a static page for the domain but, of course, I think "docs.sanicframework.org" could point to RTD.I mean, we are all working on something for Sanic and when all variables become available, we'll see what's best for each situation :-)
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/CANw3zWmKtCqwAaE6nBSMZdyFGZV4Fbiq7tdPiUZ6OMq_CqJCMw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sanic-dev/LNI1cvw--3-1%40amhopkins.com.