I have come to realize that asking for conversions of the devguide and peps
repos to test with really won't give an accurate representation of how the
workflows will apply to the cpython repository. Because of that I would
like to see a test repo that starts from the cpython repo at some point in
time that people can use to test things such as clean patch submissions,
merge conflict submissions, etc. I'm not expecting Roundup integration for
this nor that commits be integrated back into the repository of record.
Basically I want to be able to grab a patch from Roundup and somehow apply
it against a test repo to see how the workflow will work where I play both
submitter and committer (e.g., a GitHub test repo where I can submit my own
PRs against it that I know will fully succeed or have a merge conflict to
test how things will look on both ends).
Nick and Donald, do you think you can have such a test setup up and running
by October 31 (Halloween, 88 days away)? If you honestly need more time I
am willing to extend to November 15 (the cut-off in the retail industry to
consider something in stores for Christmas, 113 days away), but I only want
to do that if you honestly think the 15 extra days will make a difference.
These dates will be enough for me and any other core developers who are
interested to try out the test repos, give me feedback, and allow me to
make a decision no later than January 1, 2016 so we can start the new year
off towards getting our workflow back on track.
If we ever want to have a nice workflow where we can automate as much as
possible, we need to figure out a way deal with our most common merge
conflict: Misc/NEWS. Thanks to shifts in the format between different minor
versions the file is pretty much guaranteed to have a conflict when doing a
merge up a version.
So how do we solve this? I can remember 3 possible solutions that have been
1. A single file per entry
2. A single file per release version of Python
3. Automating it based on commit messages
I personally prefer #3 as I hate repeating myself since I just copy and
paste the first line(s) of my commits to Misc/NEWS as it is anyway
(basically up to the first pair of newlines). We would need a way to signal
that the commit message contains nothing useful for the to-be-generated
NEWS file when it's simply a fix for a previous commit (probably some
marker that is somewhat inconspicuous like a dash on its own line or
something). In terms of the section of the NEWS file that a commit belongs,
that can once again be a marker or honestly something we drop or infer
based on what files were edited in the commit.
Since both CPython and the PEPs have GitHub mirrors, I believe it would
be helpful to have the devguide as a semi-official mirror as well.
Please let me know what next steps need to be taken to make this happen.
Up until now we have always handed out Developer privileges when someone
happens to notice a person is active on the issue tracker. Is there a
Roundup query we can run which will get us hard numbers so we don't have to
guess anymore? That way we can check the results of the query on occasion,
see who people think warrants Developer privileges, and then give those
privileges to them? That would let us get more people triaging which frees
up core dev time to do more of the committer reviews and actual committing