CRLF problems in repo
Hello folks <context> Along with a few students we were preparing to poke around inside the CPython sources. Of course it would be neat if we submitted useful patches... but since I dont expect to get there so fast I thought I'd start by setting up with git which I am more familiar with than mercurial. That resulted in some adventures... including CRLF issues. </context> Some suggestions on both python mentors list and the general user list did not seem to think these completely irrelevant so reporting here. Can submit a bug-report if it looks ok ------------------------- Mixed file -- both LF and CRLF (line 29 LF rest CRLF) Lib/venv/scripts/nt/Activate.ps1 Lib/test/decimaltestdata is a directory with mixed up files -- ie some CRLF some LF files PCbuild/readme.txt: CRLF (explicit) This is fine. Many of the following should (ideally/IMHO) be likewise CRLF (not BIN) *.sln: CRLF but marked as BIN in hgeol PC/example_nt/example.vcproj Emacs shows as Dos file; But not picked up by file; maybe other such Missing BIN pattern from .hgeol *.pdf Note that Doc/library/turtle-star.pdf exists This is most likely a bug Existent file-types with non-existent files in hgeol; Probably harmless *.vsprops *.mk *.dsp *.dsw These seem straightforward CRLF files to me; why BIN in hgeol? Lib/test/test_email/data/msg_26.txt Lib/test/coding20731.py Regards, Rusi
Rustom Mody writes:
Can submit a bug-report if it looks ok
Thanks for the post. IMO this should have gone directly to the tracker 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, (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), 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. YMMV, of course, but (2) and (3) are generic criteria for deciding whether to post or to use the tracker, so I decided to mention them.
On Thu, Jun 25, 2015 at 6:45 AM, Stephen J. Turnbull
Rustom Mody writes:
Can submit a bug-report if it looks ok
Thanks for the post. IMO this should have gone directly to the tracker
Done http://bugs.python.org/issue24507#msg245793
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, (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 (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 :-) ]
YMMV, of course, but (2) and (3) are generic criteria for deciding whether to post or to use the tracker, so I decided to mention them.
Thanks for explaining Regards Rusi
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
participants (2)
-
Rustom Mody -
Stephen J. Turnbull