[Python-Dev] CRLF problems in repo

[Stephen J. Turnbull]

Private, since it doesn't really have anything to do with evaluating
actual content.  FYI, this thread probably should have stayed on
core-mentorship for a bit and then jumped directly to the tracker.

Rustom Mody writes:

 > > because (1) you have some support for the idea that at least
 > > some of these are unintentional, and therefore candidates for
 > > alignment with the rest of the code,

This you means you,

 (2) the nature of the issue is
 > > that it's a mixed bag that is going to need to be addressed line by
 > > line, and the tracker is much better at doing that (you can piece each
 > > file out to a separate issue, and have a "master issue" that blocks on
 > > each individual issue),
 > 
 > I guess you meant generic-you here?

and this you is indeed generic-you, although it applies to your case.

BTW, my terminology "blocks" is inaccurate (though in common use on
Python channels).  The proper term is "the master issue *depends* on
each individual issue, and the individual issues are *dependencies* of
the master issue."

 > > and (3) these are "easy bugs", so that new contributors (eg, your
 > > students) could do the actual patches while discussion of the
 > > need is ongoing.
 > 
 > I thought of that but if this meant a rather obese patch with really
 > minor real-contents I assumed this would be premature [for me :-) ]

The point of splitting up the task according to different files is so
that each one would get a patch, which could be done by several
students (or 3rd parties) individually without coordinating
explicitly.  Of course you might personally want to take
responsibility to screen your students' work, but that's not necessary
with this scheme unless your students are very inexperienced and
immature, like junior high school.  (I don't know what level you're
talking about, I'd guess college so this warning doesn't apply.  And
of course even junior high school students can be reliable -- I think
the record youngest committer got the privilege at age 15.  I think
that's very cool. :-)  And of course this is all up to your judgment.

Then the submitted patch would be reviewed "this is better, apply"
(which needs to be done by a developer with commit privilege, so at
that point they have to review the patch) or "this is
unecessary/inappropriate, mark invalid/wontfix and close."  After
resolving the particular issue, the "master" issue will show fewer
blockers.

I don't think this particular technique is discussed in the
developer's Guide, but that's the best source for a concise complete
description of the submit-review-commit process in Python.  I think
you mentioned you already read the Developers' Guide but it's easier
to repost the URL than search for that post.

https://docs.python.org/devguide/

Regards,
Steve