[Python-Dev] My thinking about the development process

[Brett Cannon]

On Mon Dec 08 2014 at 3:27:43 PM Jim J. Jewett <jimjjewett at gmail.com> wrote:

>
>
> Brett Cannon wrote:
> > 4. Contributor creates account on bugs.python.org and signs the
> >   [contributor agreement](https://www.python.
> org/psf/contrib/contrib-form/)
>
> Is there an expiration on such forms?  If there doesn't need to be
> (and one form is good for multiple tickets), is there an objection
> (besides "not done yet") to making "signed the form" part of the bug
> reporter account, and required to submit to the CI process?  (An "I
> can't sign yet, bug me later" option would allow the current workflow
> without the "this isn't technically a patch" workaround for "small enough"
> patches from those with slow-moving employers.)
>

IANAL but I believe that as long as you didn't sign on behalf of work for
your employer it's good for life.


>
>
> > There's the simple spelling mistake patches and then there's the
> > code change patches.
>
> There are a fair number of one-liner code patches; ideally, they
> could also be handled quickly.
>

Depends on the change. Syntactic typos could still get through. But yes,
they are also a possibility for a quick submission.


>
> > For the code change patches, contributors need an easy way to get a hold
> of
> > the code and get their changes to the core developers.
>
> For a fair number of patches, the same workflow as spelling errors is
> appropriate, except that it would be useful to have an automated state
> saying "yes, this currently merges fine", so that committers can focus
> only on patches that are (still) at least that ready.
>
> > At best core developers tell a contributor "please send your PR
> > against 3.4", push-button merge it, update a local clone, merge from
> > 3.4 to default, do the usual stuff, commit, and then push;
>
> Is it common for a patch that should apply to multiple branches to fail
> on some but not all of them?
>

Going from 3.4 -> 3.5 is almost always clean sans NEWS, but from 2.7 it is
no where near as guaranteed.


>
> In other words, is there any reason beyond "not done yet" that submitting
> a patch (or pull request) shouldn't automatically create a patch per
> branch, with pushbuttons to test/reject/commit?
>

Assuming that you specify which branches, then not really. But if it is
blindly then yes as that's unnecessary noise and could lead to arguments
over whether something should (not) be applied to some specific version.


>
> > Our code review tool is a fork that probably should be
> > replaced as only Martin von Loewis can maintain it.
>
> Only he knows the innards, or only he is authorized, or only he knows
> where the code currently is/how to deploy an update?
>

Innards.

-Brett


>
> I know that there were times in the (not-so-recent) past when I had
> time and willingness to help with some part of the infrastructure, but
> didn't know where the code was, and didn't feel right making a blind
> offer.
>
>
> -jJ
>
> --
>
> If there are still threading problems with my replies, please
> email me with details, so that I can try to resolve them.  -jJ
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20141208/facd134d/attachment.html>