https://bitbucket.org/pypa/pypi/pull-request/7/fix-development-mode/diff This allows to run PyPI on local machine without configuring web server, and fixes CSS warnings from Chrome. -- anatoly t.
Please stop submitting pull requests. Development on the existing codebase is halted except for critical fixes or security issues. You are making extra work for people on this list and it will not be tolerated. Please consider this your final warning. --Noah On Oct 30, 2013, at 1:07 PM, anatoly techtonik <techtonik@gmail.com> wrote:
https://bitbucket.org/pypa/pypi/pull-request/7/fix-development-mode/diff
This allows to run PyPI on local machine without configuring web server, and fixes CSS warnings from Chrome. -- anatoly t. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Wed, Oct 30, 2013 at 11:11 PM, Noah Kantrowitz <noah@coderanger.net> wrote:
Please stop submitting pull requests. Development on the existing codebase is halted except for critical fixes or security issues. You are making extra work for people on this list and it will not be tolerated. Please consider this your final warning.
I can't live as long as you are to see the new incantation of Python website (by PyCon 2013) or PyPI. I am willing to help, and this stuff you're saying is rather discouraging and like "no, go waste your time somewhere else, we are not giving any code reviews for free". I understand that my reputation precedes me, but can we keep this strictly technical? What I am trying to do is to send small, incremental fixes. They don't affect security. I can commit it directly to avoid distracting overloaded PyPI (bus factor 2) team, and you can blame me for breaking things - ok, and ban if I break something - that's also ok. If learn previous PyPI and new PyPI, I can tell people more about it, and you can expect more pull requests - not from me, for new PyPI, once it is ready. And if I am going to submit any new features, like reST validation on edit and Markdown support - the code will be more decoupled than existing one to be almost directly reused for the new site. Why I am skeptical that new site will replace old one soon? Just because I don't believe in rewrites by one man army. When you develop public resource, you need to rely on external feedback. You also need some designer guy in a team. You also need a backlog for collaboration. My ETA for new PyPI is no earlier than PyCon 2014 if Donald and Richard will be working on it full time. So, instead of all-or-nothing scenario I can try to find some help with incremental approach. -- anatoly t.
On Oct 31, 2013, at 7:32 AM, anatoly techtonik <techtonik@gmail.com> wrote:
Why I am skeptical that new site will replace old one soon? Just because I don't believe in rewrites by one man army. When you develop public resource, you need to rely on external feedback.
Warehouse is live at https://preview-pypi.python.org/ (No landing page yet)
You also need some designer guy in a team.
Have one who’ll have time in a few weeks to go over everything and make it really great :)
You also need a backlog for collaboration. My ETA for new PyPI is no earlier than PyCon 2014 if Donald and Richard will be working on it full time.
Possibly! I’m unsure of how long it will take, it’s primarily Richard and I but we’ve a few domain experts in particular pieces who have offered to help out as well when we’re ready for their pieces.
So, instead of all-or-nothing scenario I can try to find some help with incremental approach.
Mostly the problem with improving the current base is every change is particularly dangerous. The code base is large, it’s untested, and it’s not very nice. It’s extremely easy to break things by accident with seemingly unrelated change. Richard and I have both done this multiple times. So every PR we accept has a danger of breaking things. This incurs a high cognitive overload for accepting a PR because it means we have to spin up a copy of the site and manually go through and test any feature we think *might* be affected which typically catches most things but not always. It’s a time and labor intensive process which none of us enjoy and which we’ve decided not to prioritize unless the pay offs are large. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Oct 31, 2013, at 4:32 AM, anatoly techtonik <techtonik@gmail.com> wrote:
On Wed, Oct 30, 2013 at 11:11 PM, Noah Kantrowitz <noah@coderanger.net> wrote:
Please stop submitting pull requests. Development on the existing codebase is halted except for critical fixes or security issues. You are making extra work for people on this list and it will not be tolerated. Please consider this your final warning.
I can't live as long as you are to see the new incantation of Python website (by PyCon 2013) or PyPI. I am willing to help, and this stuff you're saying is rather discouraging and like "no, go waste your time somewhere else, we are not giving any code reviews for free". I understand that my reputation precedes me, but can we keep this strictly technical?
What I am trying to do is to send small, incremental fixes. They don't affect security. I can commit it directly to avoid distracting overloaded PyPI (bus factor 2) team, and you can blame me for breaking things - ok, and ban if I break something - that's also ok. If learn previous PyPI and new PyPI, I can tell people more about it, and you can expect more pull requests - not from me, for new PyPI, once it is ready.
And if I am going to submit any new features, like reST validation on edit and Markdown support - the code will be more decoupled than existing one to be almost directly reused for the new site.
Why I am skeptical that new site will replace old one soon? Just because I don't believe in rewrites by one man army. When you develop public resource, you need to rely on external feedback. You also need some designer guy in a team. You also need a backlog for collaboration. My ETA for new PyPI is no earlier than PyCon 2014 if Donald and Richard will be working on it full time. So, instead of all-or-nothing scenario I can try to find some help with incremental approach.
Your opinion is noted, however my statement stands and as I said, your continued derailment and disruption will not be tolerated. Thank you for your input. --Noah
On Thu, Oct 31, 2013 at 16:52 -0700, Noah Kantrowitz wrote:
On Oct 31, 2013, at 4:32 AM, anatoly techtonik <techtonik@gmail.com> wrote:
On Wed, Oct 30, 2013 at 11:11 PM, Noah Kantrowitz <noah@coderanger.net> wrote:
Please stop submitting pull requests. Development on the existing codebase is halted except for critical fixes or security issues. You are making extra work for people on this list and it will not be tolerated. Please consider this your final warning.
I can't live as long as you are to see the new incantation of Python website (by PyCon 2013) or PyPI. I am willing to help, and this stuff you're saying is rather discouraging and like "no, go waste your time somewhere else, we are not giving any code reviews for free". I understand that my reputation precedes me, but can we keep this strictly technical?
What I am trying to do is to send small, incremental fixes. They don't affect security. I can commit it directly to avoid distracting overloaded PyPI (bus factor 2) team, and you can blame me for breaking things - ok, and ban if I break something - that's also ok. If learn previous PyPI and new PyPI, I can tell people more about it, and you can expect more pull requests - not from me, for new PyPI, once it is ready.
And if I am going to submit any new features, like reST validation on edit and Markdown support - the code will be more decoupled than existing one to be almost directly reused for the new site.
Why I am skeptical that new site will replace old one soon? Just because I don't believe in rewrites by one man army. When you develop public resource, you need to rely on external feedback. You also need some designer guy in a team. You also need a backlog for collaboration. My ETA for new PyPI is no earlier than PyCon 2014 if Donald and Richard will be working on it full time. So, instead of all-or-nothing scenario I can try to find some help with incremental approach.
Your opinion is noted, however my statement stands and as I said, your continued derailment and disruption will not be tolerated. Thank you for your input.
Noah, I don't see Anatoly's postings here as derailment or disruption and also see no reason to cultivate such a "won't be tolerated" tone here. Offering PRs is usually a total legit activity although generally bitbucket/github is the primary place to handle them, rather than this mailing list here. Differing oppinions on how things should evolve are also daily open-source business. However, Richard and Donald (the two pypi maintainers) have made it clear where their priorities of spending their own time are. Donald in particular is heading the new pypi implementation and there are several areas of possible collaboration there. So it's obvious now that non-essential PRs on the current PyPI code base have hardly a chance of getting eye time at the moment. best, holger
holger krekel <holger <at> merlinux.eu> writes:
Your opinion is noted, however my statement stands and as I said, your
continued derailment and disruption will not be tolerated. Thank you for your input.
Noah, I don't see Anatoly's postings here as derailment or disruption and also see no reason to cultivate such a "won't be tolerated" tone here.
+1. I think the only "derailment" here is the way Anatoly has been treated for his contributions. Let's let Anatoly continue to submit and discuss his PRs and let Donald do whatever he wants to do whenever he wants to do it.
On 3 Nov 2013 04:26, "Alex Clark" <aclark@aclark.net> wrote:
holger krekel <holger <at> merlinux.eu> writes:
Your opinion is noted, however my statement stands and as I said, your
continued derailment and disruption will not be tolerated. Thank you for your input.
Noah, I don't see Anatoly's postings here as derailment or disruption and also see no reason to cultivate such a "won't be tolerated" tone here.
+1. I think the only "derailment" here is the way Anatoly has been treated for his contributions. Let's let Anatoly continue to submit and discuss
his
PRs and let Donald do whatever he wants to do whenever he wants to do it.
For the public record: there's additional context here related to Anatoly's interaction with the core CPython development team over the span of years. Noah's response isn't related just to these pull requests, but is informed by that past history. (I'm not going to go into any more detail here, but if anyone is really interested in the specifics, the relevant discussion is in the public archives for the python-committers list) Regards, Nick.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
participants (6)
-
Alex Clark -
anatoly techtonik -
Donald Stufft -
holger krekel -
Nick Coghlan -
Noah Kantrowitz