> On Nov 21, 2014, at 3:04 PM, Ned Deily <n...@acm.org> wrote:
>
> In article <20141121102647.46e97...@limelight.wooz.org>,
> Barry Warsaw <ba...@python.org> wrote:
>
>> On Nov 21, 2014, at 10:36 PM, Nick Coghlan wrote:
>>
>>> I'd been taking "must be hosted in PSF infrastructure" as a hard
>>> requirement, but MAL pointed out earlier this evening that in the age
>>> of DVCS's, that requirement may not make sense: if you avoid tightly
>>> coupling your automation to a particular DVCS host's infrastructure,
>>> then reverting back to self-hosting (if that becomes necessary for
>>> some reason) is mostly just a matter of "hg push".
>>>
>>> If that "must be self-hosted" constraint is removed, then the obvious
>>> candidate for Mercurial hosting that supports online editing + pull
>>> requests is the PSF's BitBucket account.
>>
>> For the record, I object to moving *official* PSF resources to proprietary,
>> closed-source infrastructure that we do not control or have access to[*].
>>
>> As nice and friendly as BitBucket or any other code hosting source is today,
>> there are many reasons why I think this is a bad idea for *official*
>> branches. We are beholden to their policies and operations, which may not
>> align with PSF policies or principles today or in the future. We will not be
>> able to customize the experience for our own needs. We will not have access
>> to the underlying resources should we need them for any purpose. We cannot
>> take action ourselves if some problem occurs, e.g. banning an offensive user.
>>
>> You're right that in a world of dvcs, branches can be mirrored anywhere. For
>> that reason, I have no problem allowing developers to use non-PSF controlled
>> resources *unofficially* if it makes their work easier and doesn't conflict
>> with their own principles. However, in such cases, I still believe that the
>> official, master, blessed repositories remain on PSF controlled
>> infrastructure. Surely that too is possible in the world of dvcs, right?
>
> I agree with Barry's arguments.
>
> Another issue, so to speak, is what to do about issues? Bitbucket,
> Github, et al provide integrated issue trackers - like we do with the
> current hg.python.org / bugs.python.org integration. If we were to move
> the official repos to another site, then what about the official site
> for issues? If we don't move the issues as well, some of the power and
> advantages of using the third-party site are lost (no one-click moving
> between issues and source, etc.). If we do move the issues, then we
> have a new source of confusion as to where people should open bugs
> (adding to the bug janitors workload), the problem of issue history
> (older and open issues in one tracker, newer ones in another), and a
> different workflow for tracking the issues.
>
> bugs.python.org already supports a kind of pull request with the "Remote
> hg repo" field. If the goal is to make it easier for newcomers to
> contribute via pull requests, perhaps that field could be better
> documented (like adding specific instructions to a readme on the
> Bitbucket read-only mirror) or improved, if necessary.
>
> https://docs.python.org/devguide/triaging.html#mercurial-repository
Well you can’t document your way out of a bad UX. The thing you’re
competing with (on Github at least) is:
1. I notice a docs change I can make
2. I click the “Edit” button and it automatically creates a fork,
and opens up a web based editor where I can make changes to
that file.
3. I fill out the commit message and hit Save.
4. An automatic pull request is opened up with my changes.
I can submit a fix for a typo in the docs in like ~30 seconds assuming
I already have a Github account. That sort of instant win is a great
way to get people started contributing to a project and can lead later
to bigger more substantial contributions.
In contrast as a non core developer right now I have to:
1. Clone the hg repository
A. Possibly this requires installing Mercurial and learning how to
clone mercurial if I don’t already know how to do that.
2. Re-find the file and open it up in a text editor and make my changes.
3. Generate a patch
A. Again this possibly involves figuring out how to create such a patch.
4. Create an issue on bugs.python.org describing the typo and upload my
patch.
This would probably take me at least 10-15 minutes to do and I already know
the tooling involved well enough to do that much. If i wasn’t familiar that
could easily take hours in order to do a simple typo fix.
Isn’t much better on the core developer side either, assuming in both cases
that the patch is perfectly acceptable and you just need to merge it in, the
Github flow is:
1. Press big green merge button, rejoice.
2. Possibly manually merge into other branches
- This can be done via PRs if you want as well, since you can make a PR that
merges one branch into another via the web UI and press the big green
button on that too.
The current flow is:
1. Download the .patch file.
2. Apply the patch file.
- Unlike in the PR style flow, you can’t know ahead of time if this
patch is going to cleanly apply or not. This may involve needing
to rework the patch which makes it hard to judge the relative level
of effort to land any one patch.
3. Commit and push the changes.
4. Possibly manually merge into other branches.
Again the PR flow here takes almost no time, like 10 seconds once you’ve
reviewed
the PR and decided it’s good to land. Maybe another minute or two if you’re
going
to use the web to merge it into other branches, or a few extra minutes if you’re
going to do it manually. The current flow is again probably a good 10-15 minutes
worth of effort to land even a tiny one letter change.
I’m not going to say that we need to switch to Github/Bitbucket to get this sort
of ease of use however those platforms do come with it and it is pretty awesome.
There are self hosted options that offer similar things (often times not quite
as
good in the ease of use though they might be more featureful in other areas).
Mostly what I’m trying to say is that documenting a field that essentially
requires
the end user to not only figure out how to use mercurial, but figure out how to
host a public repository somewhere is not even really within the same order of
magnitude in ease of use.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
