[Catalog-sig] PyPI pull request
techtonik at gmail.com
Sun May 13 11:02:20 CEST 2012
On Sat, May 12, 2012 at 6:24 PM, Daniel Greenfeld <pydanny at gmail.com> wrote:
> Also, the pattern I described to you fits very well within the
> beautiful promise of DVCS. The cleaner branching and merging of DVCS
> makes this sort of approach wonderful for all parties involved. Rather
> than giant, monolithic pull requests with lots of tiny commits, they
> get very easy to integrate pull requests.
With all respect to abstract theories I can't immediately see how it
applies to Mercurial in this particular case.
> Smaller, atomic pieces are much easier to handle then larger
> multi-task components. Isn't that the promise of OOP and functional
> programming? :-)
The contribution process is two fold. If maintainers are too picky
about bells and whistles surrounding the submitted patches (as I do
too) you can expect a significant drop in amount of people who want to
submit those patches. That's one of the reasons some project have a
lot of contributors and other are not.
> On Sat, May 12, 2012 at 8:09 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>> Hi Daniel,
>> You're request and proposed action would be nice if it used Mercurial,
>> but it uses Git + GitHub and have
>> no idea how to apply it to Mercurial + Bitbucket. If I understand you
>> correctly for every 7 commits in queue I need to make a separate clone
>> and commit it separately. That's far from the that beautiful promise
>> DVCS made. =)
>> All commits are available in pull request separately. If you take
>> another look at
>> you'll see there is an ongoing discussion over a questionable commit
>> with Martin. Feel free to comment on any revision. I can rework them
>> one by one on request if they are taking too much time to review.
>> Your wish is valid and well understood, but for specific big features.
>> For a series of small clean up changes such as this one this places a
>> more constrain on the person submitting changes. So unless there is a
>> comment that code is too complicated, I'd prefer to save this extra
>> time to polishing other aspects.
>> There are also 4 more commits in my copy waiting for this review to
>> complete, which I deliberately doesn't add to this request to
>> On Sat, May 12, 2012 at 4:17 PM, Daniel Greenfeld <pydanny at gmail.com> wrote:
>>> Here's a major issues with your pull request:
>>> It's not atomic enough. PyPI is a massive effort so any pull request
>>> should be as small as possible. For example, "running without sentry
>>> client" should be just a single pull request. By combining multiple
>>> "actions" into one pull requests, you've made it harder for the PyPI
>>> authors to evaluate your work. Which means they'll be less inclined to
>>> review it.
>>> Break this up into 3 separate pull requests. It's easy to do with
>>> branching, and the maintainers of the project will appreciate you for
>>> In fact, one thing we did with Open Comparison
>>> (http://djangopackages.com, http://pyramid.opencomparison.org, and
>>> soon http://python.opencomparison.org) that as helped us a lot as
>>> maintainers is write a formal contributing document that spells this
>>> out and more. See:
>>> and in your case, specifically:
>>> I suggest to Richard and Martin they adopt something similar. Or they
>>> can use our contributing rules in the same manner as Read the Docs:
>>> On Sat, May 12, 2012 at 2:21 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>>>> On Wed, May 9, 2012 at 1:51 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>>>>> Anybody to merge my changes from
>>>>> https://bitbucket.org/techtonik/pypi-techtonik ?
>>>> Richard told me he is busy preparing for the PyCon AU and
>>>> administering ongoing PyGame, so no help here.
>>>> Martin told it will take time. So, anybody else at least to review and comment?
>>>> I also sent mail to PSF requesting a new `pydotorg` account on
>>>> Bitbucket, so that there will be a permanent home for official mirror
>>>> for PyPI that can be found using Bitbucket search along with other
>>>> open repositories for web to send pull requests to.
>>>> In the meanwhile there few more clean up changes, one of which loosens
>>>> dependency on M2Crypto, which is not installable in virtualenv if you
>>>> don't have SWIG installed systemwide. Although it doesn't remove it
>>>> completely yet. The goal is to make pycrypto an optional alternative
>>>> for M2Crypto for an easy development.
>>>> Catalog-SIG mailing list
>>>> Catalog-SIG at python.org
>>> 'Knowledge is Power'
>>> Daniel Greenfeld
> 'Knowledge is Power'
> Daniel Greenfeld
More information about the Catalog-SIG